2019-11-14 18:02:54 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
|
|
|
config HAVE_ARCH_KCSAN
|
|
|
|
bool
|
|
|
|
|
kcsan: Restrict supported compilers
The first version of Clang that supports -tsan-distinguish-volatile will
be able to support KCSAN. The first Clang release to do so, will be
Clang 11. This is due to satisfying all the following requirements:
1. Never emit calls to __tsan_func_{entry,exit}.
2. __no_kcsan functions should not call anything, not even
kcsan_{enable,disable}_current(), when using __{READ,WRITE}_ONCE => Requires
leaving them plain!
3. Support atomic_{read,set}*() with KCSAN, which rely on
arch_atomic_{read,set}*() using __{READ,WRITE}_ONCE() => Because of
#2, rely on Clang 11's -tsan-distinguish-volatile support. We will
double-instrument atomic_{read,set}*(), but that's reasonable given
it's still lower cost than the data_race() variant due to avoiding 2
extra calls (kcsan_{en,dis}able_current() calls).
4. __always_inline functions inlined into __no_kcsan functions are never
instrumented.
5. __always_inline functions inlined into instrumented functions are
instrumented.
6. __no_kcsan_or_inline functions may be inlined into __no_kcsan functions =>
Implies leaving 'noinline' off of __no_kcsan_or_inline.
7. Because of #6, __no_kcsan and __no_kcsan_or_inline functions should never be
spuriously inlined into instrumented functions, causing the accesses of the
__no_kcsan function to be instrumented.
Older versions of Clang do not satisfy #3. The latest GCC currently
doesn't support at least #1, #3, and #7.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com
Link: https://lkml.kernel.org/r/20200521142047.169334-7-elver@google.com
2020-05-21 14:20:42 +00:00
|
|
|
config HAVE_KCSAN_COMPILER
|
2020-06-18 09:31:16 +00:00
|
|
|
def_bool (CC_IS_CLANG && $(cc-option,-fsanitize=thread -mllvm -tsan-distinguish-volatile=1)) || \
|
|
|
|
(CC_IS_GCC && $(cc-option,-fsanitize=thread --param tsan-distinguish-volatile=1))
|
kcsan: Restrict supported compilers
The first version of Clang that supports -tsan-distinguish-volatile will
be able to support KCSAN. The first Clang release to do so, will be
Clang 11. This is due to satisfying all the following requirements:
1. Never emit calls to __tsan_func_{entry,exit}.
2. __no_kcsan functions should not call anything, not even
kcsan_{enable,disable}_current(), when using __{READ,WRITE}_ONCE => Requires
leaving them plain!
3. Support atomic_{read,set}*() with KCSAN, which rely on
arch_atomic_{read,set}*() using __{READ,WRITE}_ONCE() => Because of
#2, rely on Clang 11's -tsan-distinguish-volatile support. We will
double-instrument atomic_{read,set}*(), but that's reasonable given
it's still lower cost than the data_race() variant due to avoiding 2
extra calls (kcsan_{en,dis}able_current() calls).
4. __always_inline functions inlined into __no_kcsan functions are never
instrumented.
5. __always_inline functions inlined into instrumented functions are
instrumented.
6. __no_kcsan_or_inline functions may be inlined into __no_kcsan functions =>
Implies leaving 'noinline' off of __no_kcsan_or_inline.
7. Because of #6, __no_kcsan and __no_kcsan_or_inline functions should never be
spuriously inlined into instrumented functions, causing the accesses of the
__no_kcsan function to be instrumented.
Older versions of Clang do not satisfy #3. The latest GCC currently
doesn't support at least #1, #3, and #7.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com
Link: https://lkml.kernel.org/r/20200521142047.169334-7-elver@google.com
2020-05-21 14:20:42 +00:00
|
|
|
help
|
|
|
|
For the list of compilers that support KCSAN, please see
|
|
|
|
<file:Documentation/dev-tools/kcsan.rst>.
|
|
|
|
|
2019-11-14 18:02:54 +00:00
|
|
|
menuconfig KCSAN
|
2020-04-13 09:03:05 +00:00
|
|
|
bool "KCSAN: dynamic data race detector"
|
kcsan: Restrict supported compilers
The first version of Clang that supports -tsan-distinguish-volatile will
be able to support KCSAN. The first Clang release to do so, will be
Clang 11. This is due to satisfying all the following requirements:
1. Never emit calls to __tsan_func_{entry,exit}.
2. __no_kcsan functions should not call anything, not even
kcsan_{enable,disable}_current(), when using __{READ,WRITE}_ONCE => Requires
leaving them plain!
3. Support atomic_{read,set}*() with KCSAN, which rely on
arch_atomic_{read,set}*() using __{READ,WRITE}_ONCE() => Because of
#2, rely on Clang 11's -tsan-distinguish-volatile support. We will
double-instrument atomic_{read,set}*(), but that's reasonable given
it's still lower cost than the data_race() variant due to avoiding 2
extra calls (kcsan_{en,dis}able_current() calls).
4. __always_inline functions inlined into __no_kcsan functions are never
instrumented.
5. __always_inline functions inlined into instrumented functions are
instrumented.
6. __no_kcsan_or_inline functions may be inlined into __no_kcsan functions =>
Implies leaving 'noinline' off of __no_kcsan_or_inline.
7. Because of #6, __no_kcsan and __no_kcsan_or_inline functions should never be
spuriously inlined into instrumented functions, causing the accesses of the
__no_kcsan function to be instrumented.
Older versions of Clang do not satisfy #3. The latest GCC currently
doesn't support at least #1, #3, and #7.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com
Link: https://lkml.kernel.org/r/20200521142047.169334-7-elver@google.com
2020-05-21 14:20:42 +00:00
|
|
|
depends on HAVE_ARCH_KCSAN && HAVE_KCSAN_COMPILER
|
|
|
|
depends on DEBUG_KERNEL && !KASAN
|
2020-02-04 17:21:12 +00:00
|
|
|
select STACKTRACE
|
2019-11-14 18:02:54 +00:00
|
|
|
help
|
2020-04-13 09:03:05 +00:00
|
|
|
The Kernel Concurrency Sanitizer (KCSAN) is a dynamic
|
|
|
|
data-race detector that relies on compile-time instrumentation.
|
|
|
|
KCSAN uses a watchpoint-based sampling approach to detect races.
|
kcsan: Introduce KCSAN_ACCESS_ASSERT access type
The KCSAN_ACCESS_ASSERT access type may be used to introduce dummy reads
and writes to assert certain properties of concurrent code, where bugs
could not be detected as normal data races.
For example, a variable that is only meant to be written by a single
CPU, but may be read (without locking) by other CPUs must still be
marked properly to avoid data races. However, concurrent writes,
regardless if WRITE_ONCE() or not, would be a bug. Using
kcsan_check_access(&x, sizeof(x), KCSAN_ACCESS_ASSERT) would allow
catching such bugs.
To support KCSAN_ACCESS_ASSERT the following notable changes were made:
* If an access is of type KCSAN_ASSERT_ACCESS, disable various filters
that only apply to data races, so that all races that KCSAN observes are
reported.
* Bug reports that involve an ASSERT access type will be reported as
"KCSAN: assert: race in ..." instead of "data-race"; this will help
more easily distinguish them.
* Update a few comments to just mention 'races' where we do not always
mean pure data races.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-02-06 15:46:24 +00:00
|
|
|
|
2020-04-13 09:03:05 +00:00
|
|
|
While KCSAN's primary purpose is to detect data races, it
|
|
|
|
also provides assertions to check data access constraints.
|
|
|
|
These assertions can expose bugs that do not manifest as
|
|
|
|
data races.
|
2020-02-04 17:21:12 +00:00
|
|
|
|
|
|
|
See <file:Documentation/dev-tools/kcsan.rst> for more details.
|
2019-11-14 18:02:54 +00:00
|
|
|
|
|
|
|
if KCSAN
|
|
|
|
|
2020-07-24 07:00:05 +00:00
|
|
|
config CC_HAS_TSAN_COMPOUND_READ_BEFORE_WRITE
|
|
|
|
def_bool (CC_IS_CLANG && $(cc-option,-fsanitize=thread -mllvm -tsan-compound-read-before-write=1)) || \
|
|
|
|
(CC_IS_GCC && $(cc-option,-fsanitize=thread --param tsan-compound-read-before-write=1))
|
2021-06-07 12:56:47 +00:00
|
|
|
help
|
|
|
|
The compiler instruments plain compound read-write operations
|
|
|
|
differently (++, --, +=, -=, |=, &=, etc.), which allows KCSAN to
|
|
|
|
distinguish them from other plain accesses. This is currently
|
|
|
|
supported by Clang 12 or later.
|
2020-07-24 07:00:05 +00:00
|
|
|
|
2020-02-21 23:10:27 +00:00
|
|
|
config KCSAN_VERBOSE
|
|
|
|
bool "Show verbose reports with more information about system state"
|
|
|
|
depends on PROVE_LOCKING
|
|
|
|
help
|
|
|
|
If enabled, reports show more information about the system state that
|
|
|
|
may help better analyze and debug races. This includes held locks and
|
|
|
|
IRQ trace events.
|
|
|
|
|
|
|
|
While this option should generally be benign, we call into more
|
|
|
|
external functions on report generation; if a race report is
|
|
|
|
generated from any one of them, system stability may suffer due to
|
|
|
|
deadlocks or recursion. If in doubt, say N.
|
|
|
|
|
2019-11-14 18:02:54 +00:00
|
|
|
config KCSAN_SELFTEST
|
|
|
|
bool "Perform short selftests on boot"
|
|
|
|
default y
|
|
|
|
help
|
2020-05-05 18:28:21 +00:00
|
|
|
Run KCSAN selftests on boot. On test failure, causes the kernel to
|
|
|
|
panic. Recommended to be enabled, ensuring critical functionality
|
|
|
|
works as intended.
|
|
|
|
|
2021-01-13 16:05:56 +00:00
|
|
|
config KCSAN_KUNIT_TEST
|
|
|
|
tristate "KCSAN test for integrated runtime behaviour" if !KUNIT_ALL_TESTS
|
|
|
|
default KUNIT_ALL_TESTS
|
2020-05-05 18:28:21 +00:00
|
|
|
depends on TRACEPOINTS && KUNIT
|
|
|
|
select TORTURE_TEST
|
|
|
|
help
|
|
|
|
KCSAN test focusing on behaviour of the integrated runtime. Tests
|
|
|
|
various race scenarios, and verifies the reports generated to
|
|
|
|
console. Makes use of KUnit for test organization, and the Torture
|
|
|
|
framework for test thread control.
|
|
|
|
|
|
|
|
Each test case may run at least up to KCSAN_REPORT_ONCE_IN_MS
|
|
|
|
milliseconds. Test run duration may be optimized by building the
|
|
|
|
kernel and KCSAN test with KCSAN_REPORT_ONCE_IN_MS set to a lower
|
|
|
|
than default value.
|
|
|
|
|
|
|
|
Say Y here if you want the test to be built into the kernel and run
|
|
|
|
during boot; say M if you want the test to build as a module; say N
|
|
|
|
if you are unsure.
|
2019-11-14 18:02:54 +00:00
|
|
|
|
|
|
|
config KCSAN_EARLY_ENABLE
|
|
|
|
bool "Early enable during boot"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
If KCSAN should be enabled globally as soon as possible. KCSAN can
|
|
|
|
later be enabled/disabled via debugfs.
|
|
|
|
|
|
|
|
config KCSAN_NUM_WATCHPOINTS
|
|
|
|
int "Number of available watchpoints"
|
|
|
|
default 64
|
|
|
|
help
|
|
|
|
Total number of available watchpoints. An address range maps into a
|
|
|
|
specific watchpoint slot as specified in kernel/kcsan/encoding.h.
|
|
|
|
Although larger number of watchpoints may not be usable due to
|
|
|
|
limited number of CPUs, a larger value helps to improve performance
|
|
|
|
due to reducing cache-line contention. The chosen default is a
|
|
|
|
conservative value; we should almost never observe "no_capacity"
|
|
|
|
events (see /sys/kernel/debug/kcsan).
|
|
|
|
|
|
|
|
config KCSAN_UDELAY_TASK
|
|
|
|
int "Delay in microseconds (for tasks)"
|
|
|
|
default 80
|
|
|
|
help
|
|
|
|
For tasks, the microsecond delay after setting up a watchpoint.
|
|
|
|
|
|
|
|
config KCSAN_UDELAY_INTERRUPT
|
|
|
|
int "Delay in microseconds (for interrupts)"
|
|
|
|
default 20
|
|
|
|
help
|
|
|
|
For interrupts, the microsecond delay after setting up a watchpoint.
|
|
|
|
Interrupts have tighter latency requirements, and their delay should
|
|
|
|
be lower than for tasks.
|
|
|
|
|
|
|
|
config KCSAN_DELAY_RANDOMIZE
|
|
|
|
bool "Randomize above delays"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
If delays should be randomized, where the maximum is KCSAN_UDELAY_*.
|
2019-11-20 09:41:43 +00:00
|
|
|
If false, the chosen delays are always the KCSAN_UDELAY_* values
|
|
|
|
as defined above.
|
2019-11-14 18:02:54 +00:00
|
|
|
|
|
|
|
config KCSAN_SKIP_WATCH
|
|
|
|
int "Skip instructions before setting up watchpoint"
|
|
|
|
default 4000
|
|
|
|
help
|
|
|
|
The number of per-CPU memory operations to skip, before another
|
|
|
|
watchpoint is set up, i.e. one in KCSAN_WATCH_SKIP per-CPU
|
|
|
|
memory operations are used to set up a watchpoint. A smaller value
|
|
|
|
results in more aggressive race detection, whereas a larger value
|
|
|
|
improves system performance at the cost of missing some races.
|
|
|
|
|
|
|
|
config KCSAN_SKIP_WATCH_RANDOMIZE
|
|
|
|
bool "Randomize watchpoint instruction skip count"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
If instruction skip count should be randomized, where the maximum is
|
|
|
|
KCSAN_WATCH_SKIP. If false, the chosen value is always
|
|
|
|
KCSAN_WATCH_SKIP.
|
|
|
|
|
2020-02-21 22:02:09 +00:00
|
|
|
config KCSAN_INTERRUPT_WATCHER
|
2021-06-15 18:39:38 +00:00
|
|
|
bool "Interruptible watchers" if !KCSAN_STRICT
|
|
|
|
default KCSAN_STRICT
|
2020-02-21 22:02:09 +00:00
|
|
|
help
|
|
|
|
If enabled, a task that set up a watchpoint may be interrupted while
|
|
|
|
delayed. This option will allow KCSAN to detect races between
|
|
|
|
interrupted tasks and other threads of execution on the same CPU.
|
|
|
|
|
|
|
|
Currently disabled by default, because not all safe per-CPU access
|
|
|
|
primitives and patterns may be accounted for, and therefore could
|
|
|
|
result in false positives.
|
|
|
|
|
2020-01-10 18:48:34 +00:00
|
|
|
config KCSAN_REPORT_ONCE_IN_MS
|
kcsan: Introduce KCSAN_ACCESS_ASSERT access type
The KCSAN_ACCESS_ASSERT access type may be used to introduce dummy reads
and writes to assert certain properties of concurrent code, where bugs
could not be detected as normal data races.
For example, a variable that is only meant to be written by a single
CPU, but may be read (without locking) by other CPUs must still be
marked properly to avoid data races. However, concurrent writes,
regardless if WRITE_ONCE() or not, would be a bug. Using
kcsan_check_access(&x, sizeof(x), KCSAN_ACCESS_ASSERT) would allow
catching such bugs.
To support KCSAN_ACCESS_ASSERT the following notable changes were made:
* If an access is of type KCSAN_ASSERT_ACCESS, disable various filters
that only apply to data races, so that all races that KCSAN observes are
reported.
* Bug reports that involve an ASSERT access type will be reported as
"KCSAN: assert: race in ..." instead of "data-race"; this will help
more easily distinguish them.
* Update a few comments to just mention 'races' where we do not always
mean pure data races.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-02-06 15:46:24 +00:00
|
|
|
int "Duration in milliseconds, in which any given race is only reported once"
|
2020-01-10 18:48:34 +00:00
|
|
|
default 3000
|
|
|
|
help
|
kcsan: Introduce KCSAN_ACCESS_ASSERT access type
The KCSAN_ACCESS_ASSERT access type may be used to introduce dummy reads
and writes to assert certain properties of concurrent code, where bugs
could not be detected as normal data races.
For example, a variable that is only meant to be written by a single
CPU, but may be read (without locking) by other CPUs must still be
marked properly to avoid data races. However, concurrent writes,
regardless if WRITE_ONCE() or not, would be a bug. Using
kcsan_check_access(&x, sizeof(x), KCSAN_ACCESS_ASSERT) would allow
catching such bugs.
To support KCSAN_ACCESS_ASSERT the following notable changes were made:
* If an access is of type KCSAN_ASSERT_ACCESS, disable various filters
that only apply to data races, so that all races that KCSAN observes are
reported.
* Bug reports that involve an ASSERT access type will be reported as
"KCSAN: assert: race in ..." instead of "data-race"; this will help
more easily distinguish them.
* Update a few comments to just mention 'races' where we do not always
mean pure data races.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-02-06 15:46:24 +00:00
|
|
|
Any given race is only reported once in the defined time window.
|
|
|
|
Different races may still generate reports within a duration that is
|
|
|
|
smaller than the duration defined here. This allows rate limiting
|
|
|
|
reporting to avoid flooding the console with reports. Setting this
|
|
|
|
to 0 disables rate limiting.
|
2020-01-10 18:48:34 +00:00
|
|
|
|
2021-06-07 12:56:47 +00:00
|
|
|
# The main purpose of the below options is to control reported data races, and
|
|
|
|
# are not expected to be switched frequently by non-testers or at runtime.
|
|
|
|
# The defaults are chosen to be conservative, and can miss certain bugs.
|
2019-11-14 18:02:54 +00:00
|
|
|
|
|
|
|
config KCSAN_REPORT_RACE_UNKNOWN_ORIGIN
|
|
|
|
bool "Report races of unknown origin"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
If KCSAN should report races where only one access is known, and the
|
|
|
|
conflicting access is of unknown origin. This type of race is
|
|
|
|
reported if it was only possible to infer a race due to a data value
|
|
|
|
change while an access is being delayed on a watchpoint.
|
|
|
|
|
2021-06-07 12:56:49 +00:00
|
|
|
config KCSAN_STRICT
|
|
|
|
bool "Strict data-race checking"
|
|
|
|
help
|
|
|
|
KCSAN will report data races with the strictest possible rules, which
|
|
|
|
closely aligns with the rules defined by the Linux-kernel memory
|
|
|
|
consistency model (LKMM).
|
|
|
|
|
2021-08-05 12:57:45 +00:00
|
|
|
config KCSAN_WEAK_MEMORY
|
|
|
|
bool "Enable weak memory modeling to detect missing memory barriers"
|
|
|
|
default y
|
|
|
|
depends on KCSAN_STRICT
|
|
|
|
# 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.
|
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>
2021-11-30 11:44:33 +00:00
|
|
|
depends on STACK_VALIDATION || CC_IS_GCC || CLANG_VERSION >= 140000
|
2021-08-05 12:57:45 +00:00
|
|
|
help
|
|
|
|
Enable support for modeling a subset of weak memory, which allows
|
|
|
|
detecting a subset of data races due to missing memory barriers.
|
|
|
|
|
|
|
|
Depends on KCSAN_STRICT, because the options strenghtening certain
|
|
|
|
plain accesses by default (depending on !KCSAN_STRICT) reduce the
|
|
|
|
ability to detect any data races invoving reordered accesses, in
|
|
|
|
particular reordered writes.
|
|
|
|
|
|
|
|
Weak memory modeling relies on additional instrumentation and may
|
|
|
|
affect performance.
|
|
|
|
|
2019-11-14 18:02:54 +00:00
|
|
|
config KCSAN_REPORT_VALUE_CHANGE_ONLY
|
|
|
|
bool "Only report races where watcher observed a data value change"
|
|
|
|
default y
|
2021-06-07 12:56:49 +00:00
|
|
|
depends on !KCSAN_STRICT
|
2019-11-14 18:02:54 +00:00
|
|
|
help
|
2019-11-20 09:41:43 +00:00
|
|
|
If enabled and a conflicting write is observed via a watchpoint, but
|
2019-11-14 18:02:54 +00:00
|
|
|
the data value of the memory location was observed to remain
|
|
|
|
unchanged, do not report the data race.
|
|
|
|
|
2020-02-04 17:21:10 +00:00
|
|
|
config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC
|
|
|
|
bool "Assume that plain aligned writes up to word size are atomic"
|
|
|
|
default y
|
2021-06-07 12:56:49 +00:00
|
|
|
depends on !KCSAN_STRICT
|
2020-02-04 17:21:10 +00:00
|
|
|
help
|
|
|
|
Assume that plain aligned writes up to word size are atomic by
|
|
|
|
default, and also not subject to other unsafe compiler optimizations
|
|
|
|
resulting in data races. This will cause KCSAN to not report data
|
|
|
|
races due to conflicts where the only plain accesses are aligned
|
|
|
|
writes up to word size: conflicts between marked reads and plain
|
|
|
|
aligned writes up to word size will not be reported as data races;
|
|
|
|
notice that data races between two conflicting plain aligned writes
|
|
|
|
will also not be reported.
|
|
|
|
|
2019-11-14 18:02:54 +00:00
|
|
|
config KCSAN_IGNORE_ATOMICS
|
|
|
|
bool "Do not instrument marked atomic accesses"
|
2021-06-07 12:56:49 +00:00
|
|
|
depends on !KCSAN_STRICT
|
2019-11-14 18:02:54 +00:00
|
|
|
help
|
2020-02-04 17:21:11 +00:00
|
|
|
Never instrument marked atomic accesses. This option can be used for
|
|
|
|
additional filtering. Conflicting marked atomic reads and plain
|
|
|
|
writes will never be reported as a data race, however, will cause
|
|
|
|
plain reads and marked writes to result in "unknown origin" reports.
|
|
|
|
If combined with CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=n, data
|
|
|
|
races where at least one access is marked atomic will never be
|
|
|
|
reported.
|
|
|
|
|
|
|
|
Similar to KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, but including unaligned
|
|
|
|
accesses, conflicting marked atomic reads and plain writes will not
|
|
|
|
be reported as data races; however, unlike that option, data races
|
|
|
|
due to two conflicting plain writes will be reported (aligned and
|
|
|
|
unaligned, if CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n).
|
2019-11-14 18:02:54 +00:00
|
|
|
|
2021-06-07 12:56:51 +00:00
|
|
|
config KCSAN_PERMISSIVE
|
|
|
|
bool "Enable all additional permissive rules"
|
|
|
|
depends on KCSAN_REPORT_VALUE_CHANGE_ONLY
|
|
|
|
help
|
|
|
|
Enable additional permissive rules to ignore certain classes of data
|
|
|
|
races (also see kernel/kcsan/permissive.h). None of the permissive
|
|
|
|
rules imply that such data races are generally safe, but can be used
|
|
|
|
to further reduce reported data races due to data-racy patterns
|
|
|
|
common across the kernel.
|
|
|
|
|
2019-11-14 18:02:54 +00:00
|
|
|
endif # KCSAN
|