From: 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>,
Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Daniel Axtens <dja@axtens.net>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-arch@vger.kernel.org
Subject: [PATCH kcsan 18/19] bitops, kcsan: Partially revert instrumentation for non-atomic bitops
Date: Mon, 31 Aug 2020 11:18:04 -0700 [thread overview]
Message-ID: <20200831181805.1833-18-paulmck@kernel.org> (raw)
In-Reply-To: <20200831181715.GA1530@paulmck-ThinkPad-P72>
From: Marco Elver <elver@google.com>
Previous to the change to distinguish read-write accesses, when
CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=y is set, KCSAN would consider
the non-atomic bitops as atomic. We want to partially revert to this
behaviour, but with one important distinction: report racing
modifications, since lost bits due to non-atomicity are certainly
possible.
Given the operations here only modify a single bit, assuming
non-atomicity of the writer is sufficient may be reasonable for certain
usage (and follows the permissible nature of the "assume plain writes
atomic" rule). In other words:
1. We want non-atomic read-modify-write races to be reported;
this is accomplished by kcsan_check_read(), where any
concurrent write (atomic or not) will generate a report.
2. We do not want to report races with marked readers, but -do-
want to report races with unmarked readers; this is
accomplished by the instrument_write() ("assume atomic
write" with Kconfig option set).
With the above rules, when KCSAN_ASSUME_PLAIN_WRITES_ATOMIC is selected,
it is hoped that KCSAN's reporting behaviour is better aligned with
current expected permissible usage for non-atomic bitops.
Note that, a side-effect of not telling KCSAN that the accesses are
read-writes, is that this information is not displayed in the access
summary in the report. It is, however, visible in inline-expanded stack
traces. For now, it does not make sense to introduce yet another special
case to KCSAN's runtime, only to cater to the case here.
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
.../asm-generic/bitops/instrumented-non-atomic.h | 30 +++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/bitops/instrumented-non-atomic.h b/include/asm-generic/bitops/instrumented-non-atomic.h
index f86234c..37363d5 100644
--- a/include/asm-generic/bitops/instrumented-non-atomic.h
+++ b/include/asm-generic/bitops/instrumented-non-atomic.h
@@ -58,6 +58,30 @@ static inline void __change_bit(long nr, volatile unsigned long *addr)
arch___change_bit(nr, addr);
}
+static inline void __instrument_read_write_bitop(long nr, volatile unsigned long *addr)
+{
+ if (IS_ENABLED(CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC)) {
+ /*
+ * We treat non-atomic read-write bitops a little more special.
+ * Given the operations here only modify a single bit, assuming
+ * non-atomicity of the writer is sufficient may be reasonable
+ * for certain usage (and follows the permissible nature of the
+ * assume-plain-writes-atomic rule):
+ * 1. report read-modify-write races -> check read;
+ * 2. do not report races with marked readers, but do report
+ * races with unmarked readers -> check "atomic" write.
+ */
+ kcsan_check_read(addr + BIT_WORD(nr), sizeof(long));
+ /*
+ * Use generic write instrumentation, in case other sanitizers
+ * or tools are enabled alongside KCSAN.
+ */
+ instrument_write(addr + BIT_WORD(nr), sizeof(long));
+ } else {
+ instrument_read_write(addr + BIT_WORD(nr), sizeof(long));
+ }
+}
+
/**
* __test_and_set_bit - Set a bit and return its old value
* @nr: Bit to set
@@ -68,7 +92,7 @@ static inline void __change_bit(long nr, volatile unsigned long *addr)
*/
static inline bool __test_and_set_bit(long nr, volatile unsigned long *addr)
{
- instrument_read_write(addr + BIT_WORD(nr), sizeof(long));
+ __instrument_read_write_bitop(nr, addr);
return arch___test_and_set_bit(nr, addr);
}
@@ -82,7 +106,7 @@ static inline bool __test_and_set_bit(long nr, volatile unsigned long *addr)
*/
static inline bool __test_and_clear_bit(long nr, volatile unsigned long *addr)
{
- instrument_read_write(addr + BIT_WORD(nr), sizeof(long));
+ __instrument_read_write_bitop(nr, addr);
return arch___test_and_clear_bit(nr, addr);
}
@@ -96,7 +120,7 @@ static inline bool __test_and_clear_bit(long nr, volatile unsigned long *addr)
*/
static inline bool __test_and_change_bit(long nr, volatile unsigned long *addr)
{
- instrument_read_write(addr + BIT_WORD(nr), sizeof(long));
+ __instrument_read_write_bitop(nr, addr);
return arch___test_and_change_bit(nr, addr);
}
--
2.9.5
next prev parent reply other threads:[~2020-08-31 18:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 18:17 [PATCH kcsan 0/19] KCSAN updates for v5.10 Paul E. McKenney
2020-08-31 18:17 ` [PATCH kcsan 01/19] kcsan: Add support for atomic builtins paulmck
2020-08-31 18:17 ` [PATCH kcsan 02/19] objtool: Add atomic builtin TSAN instrumentation to uaccess whitelist paulmck
2020-08-31 18:17 ` [PATCH kcsan 03/19] kcsan: Add atomic builtin test case paulmck
2020-08-31 18:17 ` [PATCH kcsan 04/19] kcsan: Support compounded read-write instrumentation paulmck
2020-08-31 18:17 ` [PATCH kcsan 05/19] objtool, kcsan: Add __tsan_read_write to uaccess whitelist paulmck
2020-08-31 18:17 ` [PATCH kcsan 06/19] kcsan: Skew delay to be longer for certain access types paulmck
2020-08-31 18:17 ` [PATCH kcsan 07/19] kcsan: Add missing CONFIG_KCSAN_IGNORE_ATOMICS checks paulmck
2020-08-31 18:17 ` [PATCH kcsan 08/19] kcsan: Test support for compound instrumentation paulmck
2020-08-31 18:17 ` [PATCH kcsan 09/19] instrumented.h: Introduce read-write instrumentation hooks paulmck
2020-08-31 18:17 ` [PATCH kcsan 10/19] asm-generic/bitops: Use instrument_read_write() where appropriate paulmck
2020-08-31 18:17 ` [PATCH kcsan 11/19] locking/atomics: Use read-write instrumentation for atomic RMWs paulmck
2020-08-31 18:17 ` [PATCH kcsan 12/19] kcsan: Simplify debugfs counter to name mapping paulmck
2020-08-31 18:17 ` [PATCH kcsan 13/19] kcsan: Simplify constant string handling paulmck
2020-08-31 18:18 ` [PATCH kcsan 14/19] kcsan: Remove debugfs test command paulmck
2020-08-31 18:18 ` [PATCH kcsan 15/19] kcsan: Show message if enabled early paulmck
2020-08-31 18:18 ` [PATCH kcsan 16/19] kcsan: Use pr_fmt for consistency paulmck
2020-08-31 18:18 ` [PATCH kcsan 17/19] kcsan: Optimize debugfs stats counters paulmck
2020-08-31 18:18 ` paulmck [this message]
2020-09-02 3:30 ` [PATCH kcsan 18/19] bitops, kcsan: Partially revert instrumentation for non-atomic bitops Boqun Feng
2020-09-02 6:13 ` Marco Elver
2020-09-04 1:24 ` Boqun Feng
2020-08-31 18:18 ` [PATCH kcsan 19/19] kcsan: Use tracing-safe version of prandom paulmck
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=20200831181805.1833-18-paulmck@kernel.org \
--to=paulmck@kernel.org \
--cc=andreyknvl@google.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=cai@lca.pw \
--cc=dja@axtens.net \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-team@fb.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=will@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®