Skip to content

Commit bd3d5bd

Browse files
melverpaulmckrcu
authored andcommitted
kcsan: Support WEAK_MEMORY with Clang where no objtool support exists
Clang and GCC behave a little differently when it comes to the __no_sanitize_thread attribute, which has valid reasons, and depending on context either one could be right. Traditionally, user space ThreadSanitizer [1] still expects instrumented builtin atomics (to avoid false positives) and __tsan_func_{entry,exit} (to generate meaningful stack traces), even if the function has the attribute no_sanitize("thread"). [1] https://clang.llvm.org/docs/ThreadSanitizer.html#attribute-no-sanitize-thread GCC doesn't follow the same policy (for better or worse), and removes all kinds of instrumentation if no_sanitize is added. Arguably, since this may be a problem for user space ThreadSanitizer, we expect this may change in future. Since KCSAN != ThreadSanitizer, the likelihood of false positives even without barrier instrumentation everywhere, is much lower by design. At least for Clang, however, to fully remove all sanitizer instrumentation, we must add the disable_sanitizer_instrumentation attribute, which is available since Clang 14.0. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
1 parent a015b70 commit bd3d5bd

2 files changed

Lines changed: 13 additions & 2 deletions

File tree

include/linux/compiler_types.h

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -198,9 +198,20 @@ struct ftrace_likely_data {
198198
# define __no_kasan_or_inline __always_inline
199199
#endif
200200

201-
#define __no_kcsan __no_sanitize_thread
202201
#ifdef __SANITIZE_THREAD__
202+
/*
203+
* Clang still emits instrumentation for __tsan_func_{entry,exit}() and builtin
204+
* atomics even with __no_sanitize_thread (to avoid false positives in userspace
205+
* ThreadSanitizer). The kernel's requirements are stricter and we really do not
206+
* want any instrumentation with __no_kcsan.
207+
*
208+
* Therefore we add __disable_sanitizer_instrumentation where available to
209+
* disable all instrumentation. See Kconfig.kcsan where this is mandatory.
210+
*/
211+
# define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentation
203212
# define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused
213+
#else
214+
# define __no_kcsan
204215
#endif
205216

206217
#ifndef __no_sanitize_or_inline

lib/Kconfig.kcsan

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -198,7 +198,7 @@ config KCSAN_WEAK_MEMORY
198198
# We can either let objtool nop __tsan_func_{entry,exit}() and builtin
199199
# atomics instrumentation in .noinstr.text, or use a compiler that can
200200
# implement __no_kcsan to really remove all instrumentation.
201-
depends on STACK_VALIDATION || CC_IS_GCC
201+
depends on STACK_VALIDATION || CC_IS_GCC || CLANG_VERSION >= 140000
202202
help
203203
Enable support for modeling a subset of weak memory, which allows
204204
detecting a subset of data races due to missing memory barriers.

0 commit comments

Comments
 (0)