Index: docs/LanguageExtensions.rst
===================================================================
--- docs/LanguageExtensions.rst
+++ docs/LanguageExtensions.rst
@@ -1937,8 +1937,8 @@
 Use ``__attribute__((no_sanitize_thread))`` on a function declaration
 to specify that checks for data races on plain (non-atomic) memory accesses
 should not be inserted by ThreadSanitizer.
-The function may still be instrumented by the tool
-to avoid false positives in other places.
+The function is still instrumented by the tool to avoid false positives and
+provide meaningful stack traces.
 
 .. _langext-memory_sanitizer:
 
Index: docs/ThreadSanitizer.rst
===================================================================
--- docs/ThreadSanitizer.rst
+++ docs/ThreadSanitizer.rst
@@ -91,7 +91,8 @@
 One may use the function attribute
 :ref:`no_sanitize_thread <langext-thread_sanitizer>`
 to disable instrumentation of plain (non-atomic) loads/stores in a particular function.
-ThreadSanitizer may still instrument such functions to avoid false positives.
+ThreadSanitizer still instruments such functions to avoid false positives and
+provide meaningful stack traces.
 This attribute may not be
 supported by other compilers, so we suggest to use it together with
 ``__has_feature(thread_sanitizer)``.
@@ -101,7 +102,12 @@
 
 ThreadSanitizer supports ``src`` and ``fun`` entity types in
 :doc:`SanitizerSpecialCaseList`, that can be used to suppress data race reports in
-the specified source files or functions.
+the specified source files or functions. Unlike functions marked with
+:ref:`no_sanitize_thread <langext-thread_sanitizer>` attribute,
+blacklisted functions are not instrumented at all. This can lead to false positives
+due to missed synchronization via atomic operations and missed stack frames in reports.
+If a blacklisted function is inlined into a non-blacklisted function, it will be
+instrumented.
 
 Limitations
 -----------