mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	kernel-team@fb.com, mingo@kernel.org
Cc: elver@google.com, andreyknvl@google.com, glider@google.com,
	dvyukov@google.com, cai@lca.pw, boqun.feng@gmail.com,
	"Paul E . McKenney" <paulmck@kernel.org>
Subject: [PATCH kcsan 25/29] kcsan: Support WEAK_MEMORY with Clang where no objtool support exists
Date: Tue, 14 Dec 2021 14:04:35 -0800	[thread overview]
Message-ID: <20211214220439.2236564-25-paulmck@kernel.org> (raw)
In-Reply-To: <20211214220356.GA2236323@paulmck-ThinkPad-P17-Gen-1>

From: Marco Elver <elver@google.com>

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>
---
 include/linux/compiler_types.h | 13 ++++++++++++-
 lib/Kconfig.kcsan              |  2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 1d32f4c03c9ef..3c1795fdb5686 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -198,9 +198,20 @@ struct ftrace_likely_data {
 # define __no_kasan_or_inline __always_inline
 #endif
 
-#define __no_kcsan __no_sanitize_thread
 #ifdef __SANITIZE_THREAD__
+/*
+ * Clang still emits instrumentation for __tsan_func_{entry,exit}() and builtin
+ * atomics even with __no_sanitize_thread (to avoid false positives in userspace
+ * ThreadSanitizer). The kernel's requirements are stricter and we really do not
+ * want any instrumentation with __no_kcsan.
+ *
+ * Therefore we add __disable_sanitizer_instrumentation where available to
+ * disable all instrumentation. See Kconfig.kcsan where this is mandatory.
+ */
+# define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentation
 # define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused
+#else
+# define __no_kcsan
 #endif
 
 #ifndef __no_sanitize_or_inline
diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index e4394ea8068b0..63b70b8c55519 100644
--- a/lib/Kconfig.kcsan
+++ b/lib/Kconfig.kcsan
@@ -198,7 +198,7 @@ config KCSAN_WEAK_MEMORY
 	# We can either let objtool nop __tsan_func_{entry,exit}() and builtin
 	# atomics instrumentation in .noinstr.text, or use a compiler that can
 	# implement __no_kcsan to really remove all instrumentation.
-	depends on STACK_VALIDATION || CC_IS_GCC
+	depends on STACK_VALIDATION || CC_IS_GCC || CLANG_VERSION >= 140000
 	help
 	  Enable support for modeling a subset of weak memory, which allows
 	  detecting a subset of data races due to missing memory barriers.
-- 
2.31.1.189.g2e36527f23


  parent reply	other threads:[~2021-12-14 22:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 22:03 [PATCH kcsan 0/29] Kernel Concurrency Sanitizer (KCSAN) updates for v5.17 Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 01/29] kcsan: Refactor reading of instrumented memory Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 02/29] kcsan: Remove redundant zero-initialization of globals Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 03/29] kcsan: Avoid checking scoped accesses from nested contexts Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 04/29] kcsan: Add core support for a subset of weak memory modeling Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 05/29] kcsan: Add core memory barrier instrumentation functions Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 06/29] kcsan, kbuild: Add option for barrier instrumentation only Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 07/29] kcsan: Call scoped accesses reordered in reports Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 08/29] kcsan: Show location access was reordered to Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 09/29] kcsan: Document modeling of weak memory Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 10/29] kcsan: test: Match reordered or normal accesses Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 11/29] kcsan: test: Add test cases for memory barrier instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 12/29] kcsan: Ignore GCC 11+ warnings about TSan runtime support Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 13/29] kcsan: selftest: Add test case to check memory barrier instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 14/29] locking/barriers, kcsan: Add instrumentation for barriers Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 15/29] locking/barriers, kcsan: Support generic instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 16/29] locking/atomics, kcsan: Add instrumentation for barriers Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 17/29] asm-generic/bitops, " Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 18/29] x86/barriers, kcsan: Use generic instrumentation for non-smp barriers Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 19/29] x86/qspinlock, kcsan: Instrument barrier of pv_queued_spin_unlock() Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 20/29] mm, kcsan: Enable barrier instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 21/29] sched, kcsan: Enable memory " Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 22/29] objtool, kcsan: Add memory barrier instrumentation to whitelist Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 23/29] objtool, kcsan: Remove memory barrier instrumentation from noinstr Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 24/29] compiler_attributes.h: Add __disable_sanitizer_instrumentation Paul E. McKenney
2021-12-14 22:04 ` Paul E. McKenney [this message]
2021-12-14 22:04 ` [PATCH kcsan 26/29] kcsan: Make barrier tests compatible with lockdep Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 27/29] kcsan: Turn barrier instrumentation into macros Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 28/29] kcsan: Avoid nested contexts reading inconsistent reorder_access Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 29/29] kcsan: Only test clear_bit_unlock_is_negative_byte if arch defines it Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211214220439.2236564-25-paulmck@kernel.org \
    --to=paulmck@kernel.org \
    --cc=andreyknvl@google.com \
    --cc=boqun.feng@gmail.com \
    --cc=cai@lca.pw \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®