2019-11-14 21:02:54 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2021-01-15 20:09:53 +03:00
|
|
|
/*
|
|
|
|
* KCSAN core runtime.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2019, Google LLC.
|
|
|
|
*/
|
2019-11-14 21:02:54 +03:00
|
|
|
|
2020-07-31 11:17:22 +03:00
|
|
|
#define pr_fmt(fmt) "kcsan: " fmt
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
#include <linux/atomic.h>
|
|
|
|
#include <linux/bug.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/init.h>
|
2020-02-04 20:21:10 +03:00
|
|
|
#include <linux/kernel.h>
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
#include <linux/list.h>
|
2020-02-07 21:59:10 +03:00
|
|
|
#include <linux/moduleparam.h>
|
2019-11-14 21:02:54 +03:00
|
|
|
#include <linux/percpu.h>
|
|
|
|
#include <linux/preempt.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
|
|
|
|
#include "atomic.h"
|
|
|
|
#include "encoding.h"
|
|
|
|
#include "kcsan.h"
|
|
|
|
|
2020-02-07 21:59:10 +03:00
|
|
|
static bool kcsan_early_enable = IS_ENABLED(CONFIG_KCSAN_EARLY_ENABLE);
|
2020-02-22 02:10:27 +03:00
|
|
|
unsigned int kcsan_udelay_task = CONFIG_KCSAN_UDELAY_TASK;
|
|
|
|
unsigned int kcsan_udelay_interrupt = CONFIG_KCSAN_UDELAY_INTERRUPT;
|
2020-02-07 21:59:10 +03:00
|
|
|
static long kcsan_skip_watch = CONFIG_KCSAN_SKIP_WATCH;
|
2020-02-22 01:02:09 +03:00
|
|
|
static bool kcsan_interrupt_watcher = IS_ENABLED(CONFIG_KCSAN_INTERRUPT_WATCHER);
|
2020-02-07 21:59:10 +03:00
|
|
|
|
|
|
|
#ifdef MODULE_PARAM_PREFIX
|
|
|
|
#undef MODULE_PARAM_PREFIX
|
|
|
|
#endif
|
|
|
|
#define MODULE_PARAM_PREFIX "kcsan."
|
|
|
|
module_param_named(early_enable, kcsan_early_enable, bool, 0);
|
|
|
|
module_param_named(udelay_task, kcsan_udelay_task, uint, 0644);
|
|
|
|
module_param_named(udelay_interrupt, kcsan_udelay_interrupt, uint, 0644);
|
|
|
|
module_param_named(skip_watch, kcsan_skip_watch, long, 0644);
|
2020-02-22 01:02:09 +03:00
|
|
|
module_param_named(interrupt_watcher, kcsan_interrupt_watcher, bool, 0444);
|
2020-02-07 21:59:10 +03:00
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
bool kcsan_enabled;
|
|
|
|
|
|
|
|
/* Per-CPU kcsan_ctx for interrupts */
|
|
|
|
static DEFINE_PER_CPU(struct kcsan_ctx, kcsan_cpu_ctx) = {
|
2019-11-20 12:41:43 +03:00
|
|
|
.disable_count = 0,
|
|
|
|
.atomic_next = 0,
|
|
|
|
.atomic_nest_count = 0,
|
|
|
|
.in_flat_atomic = false,
|
2020-02-11 19:04:22 +03:00
|
|
|
.access_mask = 0,
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
.scoped_accesses = {LIST_POISON1, NULL},
|
2019-11-14 21:02:54 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2020-03-05 17:21:07 +03:00
|
|
|
* Helper macros to index into adjacent slots, starting from address slot
|
2019-11-14 21:02:54 +03:00
|
|
|
* itself, followed by the right and left slots.
|
|
|
|
*
|
|
|
|
* The purpose is 2-fold:
|
|
|
|
*
|
|
|
|
* 1. if during insertion the address slot is already occupied, check if
|
|
|
|
* any adjacent slots are free;
|
|
|
|
* 2. accesses that straddle a slot boundary due to size that exceeds a
|
|
|
|
* slot's range may check adjacent slots if any watchpoint matches.
|
|
|
|
*
|
|
|
|
* Note that accesses with very large size may still miss a watchpoint; however,
|
|
|
|
* given this should be rare, this is a reasonable trade-off to make, since this
|
|
|
|
* will avoid:
|
|
|
|
*
|
|
|
|
* 1. excessive contention between watchpoint checks and setup;
|
|
|
|
* 2. larger number of simultaneous watchpoints without sacrificing
|
|
|
|
* performance.
|
|
|
|
*
|
|
|
|
* Example: SLOT_IDX values for KCSAN_CHECK_ADJACENT=1, where i is [0, 1, 2]:
|
|
|
|
*
|
|
|
|
* slot=0: [ 1, 2, 0]
|
|
|
|
* slot=9: [10, 11, 9]
|
|
|
|
* slot=63: [64, 65, 63]
|
|
|
|
*/
|
|
|
|
#define SLOT_IDX(slot, i) (slot + ((i + KCSAN_CHECK_ADJACENT) % NUM_SLOTS))
|
|
|
|
|
|
|
|
/*
|
2019-11-20 12:41:43 +03:00
|
|
|
* SLOT_IDX_FAST is used in the fast-path. Not first checking the address's primary
|
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 18:46:24 +03:00
|
|
|
* slot (middle) is fine if we assume that races occur rarely. The set of
|
2019-11-14 21:02:54 +03:00
|
|
|
* indices {SLOT_IDX(slot, i) | i in [0, NUM_SLOTS)} is equivalent to
|
|
|
|
* {SLOT_IDX_FAST(slot, i) | i in [0, NUM_SLOTS)}.
|
|
|
|
*/
|
|
|
|
#define SLOT_IDX_FAST(slot, i) (slot + i)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Watchpoints, with each entry encoded as defined in encoding.h: in order to be
|
|
|
|
* able to safely update and access a watchpoint without introducing locking
|
|
|
|
* overhead, we encode each watchpoint as a single atomic long. The initial
|
|
|
|
* zero-initialized state matches INVALID_WATCHPOINT.
|
|
|
|
*
|
|
|
|
* Add NUM_SLOTS-1 entries to account for overflow; this helps avoid having to
|
2019-11-20 12:41:43 +03:00
|
|
|
* use more complicated SLOT_IDX_FAST calculation with modulo in the fast-path.
|
2019-11-14 21:02:54 +03:00
|
|
|
*/
|
2019-11-20 12:41:43 +03:00
|
|
|
static atomic_long_t watchpoints[CONFIG_KCSAN_NUM_WATCHPOINTS + NUM_SLOTS-1];
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Instructions to skip watching counter, used in should_watch(). We use a
|
|
|
|
* per-CPU counter to avoid excessive contention.
|
|
|
|
*/
|
|
|
|
static DEFINE_PER_CPU(long, kcsan_skip);
|
|
|
|
|
2020-08-21 15:31:26 +03:00
|
|
|
/* For kcsan_prandom_u32_max(). */
|
2020-11-24 14:02:09 +03:00
|
|
|
static DEFINE_PER_CPU(u32, kcsan_rand_state);
|
2020-08-21 15:31:26 +03:00
|
|
|
|
2020-01-07 19:31:04 +03:00
|
|
|
static __always_inline atomic_long_t *find_watchpoint(unsigned long addr,
|
|
|
|
size_t size,
|
|
|
|
bool expect_write,
|
|
|
|
long *encoded_watchpoint)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
|
|
|
const int slot = watchpoint_slot(addr);
|
|
|
|
const unsigned long addr_masked = addr & WATCHPOINT_ADDR_MASK;
|
|
|
|
atomic_long_t *watchpoint;
|
|
|
|
unsigned long wp_addr_masked;
|
|
|
|
size_t wp_size;
|
|
|
|
bool is_write;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(CONFIG_KCSAN_NUM_WATCHPOINTS < NUM_SLOTS);
|
|
|
|
|
|
|
|
for (i = 0; i < NUM_SLOTS; ++i) {
|
|
|
|
watchpoint = &watchpoints[SLOT_IDX_FAST(slot, i)];
|
|
|
|
*encoded_watchpoint = atomic_long_read(watchpoint);
|
|
|
|
if (!decode_watchpoint(*encoded_watchpoint, &wp_addr_masked,
|
|
|
|
&wp_size, &is_write))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (expect_write && !is_write)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Check if the watchpoint matches the access. */
|
|
|
|
if (matching_access(wp_addr_masked, wp_size, addr_masked, size))
|
|
|
|
return watchpoint;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-11-20 12:41:43 +03:00
|
|
|
static inline atomic_long_t *
|
|
|
|
insert_watchpoint(unsigned long addr, size_t size, bool is_write)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
|
|
|
const int slot = watchpoint_slot(addr);
|
|
|
|
const long encoded_watchpoint = encode_watchpoint(addr, size, is_write);
|
|
|
|
atomic_long_t *watchpoint;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Check slot index logic, ensuring we stay within array bounds. */
|
|
|
|
BUILD_BUG_ON(SLOT_IDX(0, 0) != KCSAN_CHECK_ADJACENT);
|
2019-11-20 12:41:43 +03:00
|
|
|
BUILD_BUG_ON(SLOT_IDX(0, KCSAN_CHECK_ADJACENT+1) != 0);
|
|
|
|
BUILD_BUG_ON(SLOT_IDX(CONFIG_KCSAN_NUM_WATCHPOINTS-1, KCSAN_CHECK_ADJACENT) != ARRAY_SIZE(watchpoints)-1);
|
|
|
|
BUILD_BUG_ON(SLOT_IDX(CONFIG_KCSAN_NUM_WATCHPOINTS-1, KCSAN_CHECK_ADJACENT+1) != ARRAY_SIZE(watchpoints) - NUM_SLOTS);
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
for (i = 0; i < NUM_SLOTS; ++i) {
|
|
|
|
long expect_val = INVALID_WATCHPOINT;
|
|
|
|
|
|
|
|
/* Try to acquire this slot. */
|
|
|
|
watchpoint = &watchpoints[SLOT_IDX(slot, i)];
|
2019-11-20 12:41:43 +03:00
|
|
|
if (atomic_long_try_cmpxchg_relaxed(watchpoint, &expect_val, encoded_watchpoint))
|
2019-11-14 21:02:54 +03:00
|
|
|
return watchpoint;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return true if watchpoint was successfully consumed, false otherwise.
|
|
|
|
*
|
|
|
|
* This may return false if:
|
|
|
|
*
|
|
|
|
* 1. another thread already consumed the watchpoint;
|
|
|
|
* 2. the thread that set up the watchpoint already removed it;
|
|
|
|
* 3. the watchpoint was removed and then re-used.
|
|
|
|
*/
|
2020-01-07 19:31:04 +03:00
|
|
|
static __always_inline bool
|
2019-11-20 12:41:43 +03:00
|
|
|
try_consume_watchpoint(atomic_long_t *watchpoint, long encoded_watchpoint)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
2019-11-20 12:41:43 +03:00
|
|
|
return atomic_long_try_cmpxchg_relaxed(watchpoint, &encoded_watchpoint, CONSUMED_WATCHPOINT);
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
/* Return true if watchpoint was not touched, false if already consumed. */
|
|
|
|
static inline bool consume_watchpoint(atomic_long_t *watchpoint)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
return atomic_long_xchg_relaxed(watchpoint, CONSUMED_WATCHPOINT) != CONSUMED_WATCHPOINT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Remove the watchpoint -- its slot may be reused after. */
|
|
|
|
static inline void remove_watchpoint(atomic_long_t *watchpoint)
|
|
|
|
{
|
|
|
|
atomic_long_set(watchpoint, INVALID_WATCHPOINT);
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
2020-01-07 19:31:04 +03:00
|
|
|
static __always_inline struct kcsan_ctx *get_ctx(void)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
|
|
|
/*
|
2019-11-20 12:41:43 +03:00
|
|
|
* In interrupts, use raw_cpu_ptr to avoid unnecessary checks, that would
|
2019-11-14 21:02:54 +03:00
|
|
|
* also result in calls that generate warnings in uaccess regions.
|
|
|
|
*/
|
|
|
|
return in_task() ? ¤t->kcsan_ctx : raw_cpu_ptr(&kcsan_cpu_ctx);
|
|
|
|
}
|
|
|
|
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
/* Check scoped accesses; never inline because this is a slow-path! */
|
|
|
|
static noinline void kcsan_check_scoped_accesses(void)
|
|
|
|
{
|
|
|
|
struct kcsan_ctx *ctx = get_ctx();
|
|
|
|
struct list_head *prev_save = ctx->scoped_accesses.prev;
|
|
|
|
struct kcsan_scoped_access *scoped_access;
|
|
|
|
|
|
|
|
ctx->scoped_accesses.prev = NULL; /* Avoid recursion. */
|
|
|
|
list_for_each_entry(scoped_access, &ctx->scoped_accesses, list)
|
|
|
|
__kcsan_check_access(scoped_access->ptr, scoped_access->size, scoped_access->type);
|
|
|
|
ctx->scoped_accesses.prev = prev_save;
|
|
|
|
}
|
|
|
|
|
2020-02-25 17:32:58 +03:00
|
|
|
/* Rules for generic atomic accesses. Called from fast-path. */
|
2020-02-04 20:21:10 +03:00
|
|
|
static __always_inline bool
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
is_atomic(const volatile void *ptr, size_t size, int type, struct kcsan_ctx *ctx)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
2020-02-25 17:32:58 +03:00
|
|
|
if (type & KCSAN_ACCESS_ATOMIC)
|
2020-02-04 20:21:10 +03:00
|
|
|
return true;
|
2019-11-14 21:02:54 +03:00
|
|
|
|
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 18:46:24 +03:00
|
|
|
/*
|
|
|
|
* Unless explicitly declared atomic, never consider an assertion access
|
|
|
|
* as atomic. This allows using them also in atomic regions, such as
|
|
|
|
* seqlocks, without implicitly changing their semantics.
|
|
|
|
*/
|
2020-02-25 17:32:58 +03:00
|
|
|
if (type & KCSAN_ACCESS_ASSERT)
|
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 18:46:24 +03:00
|
|
|
return false;
|
|
|
|
|
2020-02-04 20:21:10 +03:00
|
|
|
if (IS_ENABLED(CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC) &&
|
2020-02-25 17:32:58 +03:00
|
|
|
(type & KCSAN_ACCESS_WRITE) && size <= sizeof(long) &&
|
kcsan: Support compounded read-write instrumentation
Add support for compounded read-write instrumentation if supported by
the compiler. Adds the necessary instrumentation functions, and a new
type which is used to generate a more descriptive report.
Furthermore, such compounded memory access instrumentation is excluded
from the "assume aligned writes up to word size are atomic" rule,
because we cannot assume that the compiler emits code that is atomic for
compound ops.
LLVM/Clang added support for the feature in:
https://github.com/llvm/llvm-project/commit/785d41a261d136b64ab6c15c5d35f2adc5ad53e3
The new instrumentation is emitted for sets of memory accesses in the
same basic block to the same address with at least one read appearing
before a write. These typically result from compound operations such as
++, --, +=, -=, |=, &=, etc. but also equivalent forms such as "var =
var + 1". Where the compiler determines that it is equivalent to emit a
call to a single __tsan_read_write instead of separate __tsan_read and
__tsan_write, we can then benefit from improved performance and better
reporting for such access patterns.
The new reports now show that the ops are both reads and writes, for
example:
read-write to 0xffffffff90548a38 of 8 bytes by task 143 on cpu 3:
test_kernel_rmw_array+0x45/0xa0
access_thread+0x71/0xb0
kthread+0x21e/0x240
ret_from_fork+0x22/0x30
read-write to 0xffffffff90548a38 of 8 bytes by task 144 on cpu 2:
test_kernel_rmw_array+0x45/0xa0
access_thread+0x71/0xb0
kthread+0x21e/0x240
ret_from_fork+0x22/0x30
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-07-24 10:00:01 +03:00
|
|
|
!(type & KCSAN_ACCESS_COMPOUND) && IS_ALIGNED((unsigned long)ptr, size))
|
2020-02-04 20:21:10 +03:00
|
|
|
return true; /* Assume aligned writes up to word size are atomic. */
|
|
|
|
|
2020-02-25 17:32:58 +03:00
|
|
|
if (ctx->atomic_next > 0) {
|
2019-11-14 21:02:54 +03:00
|
|
|
/*
|
|
|
|
* Because we do not have separate contexts for nested
|
|
|
|
* interrupts, in case atomic_next is set, we simply assume that
|
|
|
|
* the outer interrupt set atomic_next. In the worst case, we
|
|
|
|
* will conservatively consider operations as atomic. This is a
|
|
|
|
* reasonable trade-off to make, since this case should be
|
|
|
|
* extremely rare; however, even if extremely rare, it could
|
|
|
|
* lead to false positives otherwise.
|
|
|
|
*/
|
|
|
|
if ((hardirq_count() >> HARDIRQ_SHIFT) < 2)
|
|
|
|
--ctx->atomic_next; /* in task, or outer interrupt */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-02-25 17:32:58 +03:00
|
|
|
return ctx->atomic_nest_count > 0 || ctx->in_flat_atomic;
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
2020-02-04 20:21:10 +03:00
|
|
|
static __always_inline bool
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
should_watch(const volatile void *ptr, size_t size, int type, struct kcsan_ctx *ctx)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Never set up watchpoints when memory operations are atomic.
|
|
|
|
*
|
|
|
|
* Need to check this first, before kcsan_skip check below: (1) atomics
|
|
|
|
* should not count towards skipped instructions, and (2) to actually
|
|
|
|
* decrement kcsan_atomic_next for consecutive instruction stream.
|
|
|
|
*/
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
if (is_atomic(ptr, size, type, ctx))
|
2019-11-14 21:02:54 +03:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (this_cpu_dec_return(kcsan_skip) >= 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: If we get here, kcsan_skip must always be reset in slow path
|
|
|
|
* via reset_kcsan_skip() to avoid underflow.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* this operation should be watched */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-08-21 15:31:26 +03:00
|
|
|
/*
|
2020-11-24 14:02:09 +03:00
|
|
|
* Returns a pseudo-random number in interval [0, ep_ro). Simple linear
|
|
|
|
* congruential generator, using constants from "Numerical Recipes".
|
2020-08-21 15:31:26 +03:00
|
|
|
*/
|
|
|
|
static u32 kcsan_prandom_u32_max(u32 ep_ro)
|
|
|
|
{
|
2020-11-24 14:02:09 +03:00
|
|
|
u32 state = this_cpu_read(kcsan_rand_state);
|
|
|
|
|
|
|
|
state = 1664525 * state + 1013904223;
|
|
|
|
this_cpu_write(kcsan_rand_state, state);
|
2020-08-21 15:31:26 +03:00
|
|
|
|
2020-11-24 14:02:09 +03:00
|
|
|
return state % ep_ro;
|
2020-08-21 15:31:26 +03:00
|
|
|
}
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
static inline void reset_kcsan_skip(void)
|
|
|
|
{
|
2020-02-07 21:59:10 +03:00
|
|
|
long skip_count = kcsan_skip_watch -
|
2019-11-14 21:02:54 +03:00
|
|
|
(IS_ENABLED(CONFIG_KCSAN_SKIP_WATCH_RANDOMIZE) ?
|
2020-08-21 15:31:26 +03:00
|
|
|
kcsan_prandom_u32_max(kcsan_skip_watch) :
|
2019-11-14 21:02:54 +03:00
|
|
|
0);
|
|
|
|
this_cpu_write(kcsan_skip, skip_count);
|
|
|
|
}
|
|
|
|
|
2020-01-07 19:31:04 +03:00
|
|
|
static __always_inline bool kcsan_is_enabled(void)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
|
|
|
return READ_ONCE(kcsan_enabled) && get_ctx()->disable_count == 0;
|
|
|
|
}
|
|
|
|
|
2020-08-21 15:31:26 +03:00
|
|
|
/* Introduce delay depending on context and configuration. */
|
|
|
|
static void delay_access(int type)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
2020-02-07 21:59:10 +03:00
|
|
|
unsigned int delay = in_task() ? kcsan_udelay_task : kcsan_udelay_interrupt;
|
2020-07-24 10:00:03 +03:00
|
|
|
/* For certain access types, skew the random delay to be longer. */
|
|
|
|
unsigned int skew_delay_order =
|
|
|
|
(type & (KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_ASSERT)) ? 1 : 0;
|
|
|
|
|
2020-08-21 15:31:26 +03:00
|
|
|
delay -= IS_ENABLED(CONFIG_KCSAN_DELAY_RANDOMIZE) ?
|
|
|
|
kcsan_prandom_u32_max(delay >> skew_delay_order) :
|
|
|
|
0;
|
|
|
|
udelay(delay);
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
2020-07-29 14:09:16 +03:00
|
|
|
void kcsan_save_irqtrace(struct task_struct *task)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
|
|
|
task->kcsan_save_irqtrace = task->irqtrace;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void kcsan_restore_irqtrace(struct task_struct *task)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_TRACE_IRQFLAGS
|
|
|
|
task->irqtrace = task->kcsan_save_irqtrace;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
/*
|
|
|
|
* Pull everything together: check_access() below contains the performance
|
|
|
|
* critical operations; the fast-path (including check_access) functions should
|
|
|
|
* all be inlinable by the instrumentation functions.
|
|
|
|
*
|
|
|
|
* The slow-path (kcsan_found_watchpoint, kcsan_setup_watchpoint) are
|
|
|
|
* non-inlinable -- note that, we prefix these with "kcsan_" to ensure they can
|
|
|
|
* be filtered from the stacktrace, as well as give them unique names for the
|
|
|
|
* UACCESS whitelist of objtool. Each function uses user_access_save/restore(),
|
|
|
|
* since they do not access any user memory, but instrumentation is still
|
|
|
|
* emitted in UACCESS regions.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static noinline void kcsan_found_watchpoint(const volatile void *ptr,
|
2019-11-20 12:41:43 +03:00
|
|
|
size_t size,
|
2020-01-10 21:48:33 +03:00
|
|
|
int type,
|
2019-11-14 21:02:54 +03:00
|
|
|
atomic_long_t *watchpoint,
|
|
|
|
long encoded_watchpoint)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
bool consumed;
|
|
|
|
|
|
|
|
if (!kcsan_is_enabled())
|
|
|
|
return;
|
2020-02-11 19:04:22 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The access_mask check relies on value-change comparison. To avoid
|
|
|
|
* reporting a race where e.g. the writer set up the watchpoint, but the
|
|
|
|
* reader has access_mask!=0, we have to ignore the found watchpoint.
|
|
|
|
*/
|
|
|
|
if (get_ctx()->access_mask != 0)
|
|
|
|
return;
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
/*
|
|
|
|
* Consume the watchpoint as soon as possible, to minimize the chances
|
|
|
|
* of !consumed. Consuming the watchpoint must always be guarded by
|
|
|
|
* kcsan_is_enabled() check, as otherwise we might erroneously
|
|
|
|
* triggering reports when disabled.
|
|
|
|
*/
|
|
|
|
consumed = try_consume_watchpoint(watchpoint, encoded_watchpoint);
|
|
|
|
|
|
|
|
/* keep this after try_consume_watchpoint */
|
|
|
|
flags = user_access_save();
|
|
|
|
|
|
|
|
if (consumed) {
|
2020-07-29 14:09:16 +03:00
|
|
|
kcsan_save_irqtrace(current);
|
2020-03-18 20:38:44 +03:00
|
|
|
kcsan_report(ptr, size, type, KCSAN_VALUE_CHANGE_MAYBE,
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
KCSAN_REPORT_CONSUMED_WATCHPOINT,
|
|
|
|
watchpoint - watchpoints);
|
2020-07-29 14:09:16 +03:00
|
|
|
kcsan_restore_irqtrace(current);
|
2019-11-14 21:02:54 +03:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The other thread may not print any diagnostics, as it has
|
|
|
|
* already removed the watchpoint, or another thread consumed
|
|
|
|
* the watchpoint before this thread.
|
|
|
|
*/
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_REPORT_RACES]);
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
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 18:46:24 +03:00
|
|
|
|
|
|
|
if ((type & KCSAN_ACCESS_ASSERT) != 0)
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_ASSERT_FAILURES]);
|
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 18:46:24 +03:00
|
|
|
else
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_DATA_RACES]);
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
user_access_restore(flags);
|
|
|
|
}
|
|
|
|
|
2019-11-20 12:41:43 +03:00
|
|
|
static noinline void
|
2020-01-10 21:48:33 +03:00
|
|
|
kcsan_setup_watchpoint(const volatile void *ptr, size_t size, int type)
|
2019-11-14 21:02:54 +03:00
|
|
|
{
|
2020-01-10 21:48:33 +03:00
|
|
|
const bool is_write = (type & KCSAN_ACCESS_WRITE) != 0;
|
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 18:46:24 +03:00
|
|
|
const bool is_assert = (type & KCSAN_ACCESS_ASSERT) != 0;
|
2019-11-14 21:02:54 +03:00
|
|
|
atomic_long_t *watchpoint;
|
|
|
|
union {
|
|
|
|
u8 _1;
|
|
|
|
u16 _2;
|
|
|
|
u32 _4;
|
|
|
|
u64 _8;
|
|
|
|
} expect_value;
|
2020-02-11 19:04:22 +03:00
|
|
|
unsigned long access_mask;
|
2020-02-11 19:04:21 +03:00
|
|
|
enum kcsan_value_change value_change = KCSAN_VALUE_CHANGE_MAYBE;
|
2019-11-14 21:02:54 +03:00
|
|
|
unsigned long ua_flags = user_access_save();
|
2020-02-22 01:02:09 +03:00
|
|
|
unsigned long irq_flags = 0;
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Always reset kcsan_skip counter in slow-path to avoid underflow; see
|
|
|
|
* should_watch().
|
|
|
|
*/
|
|
|
|
reset_kcsan_skip();
|
|
|
|
|
|
|
|
if (!kcsan_is_enabled())
|
|
|
|
goto out;
|
|
|
|
|
2020-02-25 17:32:58 +03:00
|
|
|
/*
|
|
|
|
* Special atomic rules: unlikely to be true, so we check them here in
|
|
|
|
* the slow-path, and not in the fast-path in is_atomic(). Call after
|
|
|
|
* kcsan_is_enabled(), as we may access memory that is not yet
|
|
|
|
* initialized during early boot.
|
|
|
|
*/
|
|
|
|
if (!is_assert && kcsan_is_atomic_special(ptr))
|
|
|
|
goto out;
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
if (!check_encodable((unsigned long)ptr, size)) {
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_UNENCODABLE_ACCESSES]);
|
2019-11-14 21:02:54 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2020-07-29 14:09:16 +03:00
|
|
|
/*
|
|
|
|
* Save and restore the IRQ state trace touched by KCSAN, since KCSAN's
|
|
|
|
* runtime is entered for every memory access, and potentially useful
|
|
|
|
* information is lost if dirtied by KCSAN.
|
|
|
|
*/
|
|
|
|
kcsan_save_irqtrace(current);
|
2020-02-22 01:02:09 +03:00
|
|
|
if (!kcsan_interrupt_watcher)
|
2020-06-24 14:32:46 +03:00
|
|
|
local_irq_save(irq_flags);
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
watchpoint = insert_watchpoint((unsigned long)ptr, size, is_write);
|
|
|
|
if (watchpoint == NULL) {
|
|
|
|
/*
|
2019-11-20 12:41:43 +03:00
|
|
|
* Out of capacity: the size of 'watchpoints', and the frequency
|
|
|
|
* with which should_watch() returns true should be tweaked so
|
2019-11-14 21:02:54 +03:00
|
|
|
* that this case happens very rarely.
|
|
|
|
*/
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_NO_CAPACITY]);
|
2019-11-14 21:02:54 +03:00
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_SETUP_WATCHPOINTS]);
|
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_USED_WATCHPOINTS]);
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the current value, to later check and infer a race if the data
|
|
|
|
* was modified via a non-instrumented access, e.g. from a device.
|
|
|
|
*/
|
2020-02-11 19:04:21 +03:00
|
|
|
expect_value._8 = 0;
|
2019-11-14 21:02:54 +03:00
|
|
|
switch (size) {
|
|
|
|
case 1:
|
|
|
|
expect_value._1 = READ_ONCE(*(const u8 *)ptr);
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
expect_value._2 = READ_ONCE(*(const u16 *)ptr);
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
expect_value._4 = READ_ONCE(*(const u32 *)ptr);
|
|
|
|
break;
|
|
|
|
case 8:
|
|
|
|
expect_value._8 = READ_ONCE(*(const u64 *)ptr);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break; /* ignore; we do not diff the values */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_KCSAN_DEBUG)) {
|
|
|
|
kcsan_disable_current();
|
2020-07-31 11:17:22 +03:00
|
|
|
pr_err("watching %s, size: %zu, addr: %px [slot: %d, encoded: %lx]\n",
|
2019-11-14 21:02:54 +03:00
|
|
|
is_write ? "write" : "read", size, ptr,
|
|
|
|
watchpoint_slot((unsigned long)ptr),
|
|
|
|
encode_watchpoint((unsigned long)ptr, size, is_write));
|
|
|
|
kcsan_enable_current();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delay this thread, to increase probability of observing a racy
|
|
|
|
* conflicting access.
|
|
|
|
*/
|
2020-08-21 15:31:26 +03:00
|
|
|
delay_access(type);
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Re-read value, and check if it is as expected; if not, we infer a
|
|
|
|
* racy access.
|
|
|
|
*/
|
2020-02-11 19:04:22 +03:00
|
|
|
access_mask = get_ctx()->access_mask;
|
2019-11-14 21:02:54 +03:00
|
|
|
switch (size) {
|
|
|
|
case 1:
|
2020-02-11 19:04:21 +03:00
|
|
|
expect_value._1 ^= READ_ONCE(*(const u8 *)ptr);
|
2020-02-11 19:04:22 +03:00
|
|
|
if (access_mask)
|
|
|
|
expect_value._1 &= (u8)access_mask;
|
2019-11-14 21:02:54 +03:00
|
|
|
break;
|
|
|
|
case 2:
|
2020-02-11 19:04:21 +03:00
|
|
|
expect_value._2 ^= READ_ONCE(*(const u16 *)ptr);
|
2020-02-11 19:04:22 +03:00
|
|
|
if (access_mask)
|
|
|
|
expect_value._2 &= (u16)access_mask;
|
2019-11-14 21:02:54 +03:00
|
|
|
break;
|
|
|
|
case 4:
|
2020-02-11 19:04:21 +03:00
|
|
|
expect_value._4 ^= READ_ONCE(*(const u32 *)ptr);
|
2020-02-11 19:04:22 +03:00
|
|
|
if (access_mask)
|
|
|
|
expect_value._4 &= (u32)access_mask;
|
2019-11-14 21:02:54 +03:00
|
|
|
break;
|
|
|
|
case 8:
|
2020-02-11 19:04:21 +03:00
|
|
|
expect_value._8 ^= READ_ONCE(*(const u64 *)ptr);
|
2020-02-11 19:04:22 +03:00
|
|
|
if (access_mask)
|
|
|
|
expect_value._8 &= (u64)access_mask;
|
2019-11-14 21:02:54 +03:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break; /* ignore; we do not diff the values */
|
|
|
|
}
|
|
|
|
|
2020-02-11 19:04:21 +03:00
|
|
|
/* Were we able to observe a value-change? */
|
|
|
|
if (expect_value._8 != 0)
|
|
|
|
value_change = KCSAN_VALUE_CHANGE_TRUE;
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
/* Check if this access raced with another. */
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
if (!consume_watchpoint(watchpoint)) {
|
2020-02-11 19:04:21 +03:00
|
|
|
/*
|
|
|
|
* Depending on the access type, map a value_change of MAYBE to
|
2020-02-11 19:04:22 +03:00
|
|
|
* TRUE (always report) or FALSE (never report).
|
2020-02-11 19:04:21 +03:00
|
|
|
*/
|
2020-02-11 19:04:22 +03:00
|
|
|
if (value_change == KCSAN_VALUE_CHANGE_MAYBE) {
|
|
|
|
if (access_mask != 0) {
|
|
|
|
/*
|
|
|
|
* For access with access_mask, we require a
|
|
|
|
* value-change, as it is likely that races on
|
|
|
|
* ~access_mask bits are expected.
|
|
|
|
*/
|
|
|
|
value_change = KCSAN_VALUE_CHANGE_FALSE;
|
|
|
|
} else if (size > 8 || is_assert) {
|
|
|
|
/* Always assume a value-change. */
|
|
|
|
value_change = KCSAN_VALUE_CHANGE_TRUE;
|
|
|
|
}
|
2020-02-11 19:04:21 +03:00
|
|
|
}
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
/*
|
|
|
|
* No need to increment 'data_races' counter, as the racing
|
|
|
|
* thread already did.
|
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 18:46:24 +03:00
|
|
|
*
|
|
|
|
* Count 'assert_failures' for each failed ASSERT access,
|
|
|
|
* therefore both this thread and the racing thread may
|
|
|
|
* increment this counter.
|
2019-11-14 21:02:54 +03:00
|
|
|
*/
|
2020-02-11 19:04:21 +03:00
|
|
|
if (is_assert && value_change == KCSAN_VALUE_CHANGE_TRUE)
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_ASSERT_FAILURES]);
|
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 18:46:24 +03:00
|
|
|
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
kcsan_report(ptr, size, type, value_change, KCSAN_REPORT_RACE_SIGNAL,
|
|
|
|
watchpoint - watchpoints);
|
2020-02-11 19:04:21 +03:00
|
|
|
} else if (value_change == KCSAN_VALUE_CHANGE_TRUE) {
|
2019-11-14 21:02:54 +03:00
|
|
|
/* Inferring a race, since the value should not have changed. */
|
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 18:46:24 +03:00
|
|
|
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_RACES_UNKNOWN_ORIGIN]);
|
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 18:46:24 +03:00
|
|
|
if (is_assert)
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_inc(&kcsan_counters[KCSAN_COUNTER_ASSERT_FAILURES]);
|
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 18:46:24 +03:00
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN) || is_assert)
|
2020-02-11 19:04:21 +03:00
|
|
|
kcsan_report(ptr, size, type, KCSAN_VALUE_CHANGE_TRUE,
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
KCSAN_REPORT_RACE_UNKNOWN_ORIGIN,
|
|
|
|
watchpoint - watchpoints);
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
kcsan: Avoid blocking producers in prepare_report()
To avoid deadlock in case watchers can be interrupted, we need to ensure
that producers of the struct other_info can never be blocked by an
unrelated consumer. (Likely to occur with KCSAN_INTERRUPT_WATCHER.)
There are several cases that can lead to this scenario, for example:
1. A watchpoint A was set up by task T1, but interrupted by
interrupt I1. Some other thread (task or interrupt) finds
watchpoint A consumes it, and sets other_info. Then I1 also
finds some unrelated watchpoint B, consumes it, but is blocked
because other_info is in use. T1 cannot consume other_info
because I1 never returns -> deadlock.
2. A watchpoint A was set up by task T1, but interrupted by
interrupt I1, which also sets up a watchpoint B. Some other
thread finds watchpoint A, and consumes it and sets up
other_info with its information. Similarly some other thread
finds watchpoint B and consumes it, but is then blocked because
other_info is in use. When I1 continues it sees its watchpoint
was consumed, and that it must wait for other_info, which
currently contains information to be consumed by T1. However, T1
cannot unblock other_info because I1 never returns -> deadlock.
To avoid this, we need to ensure that producers of struct other_info
always have a usable other_info entry. This is obviously not the case
with only a single instance of struct other_info, as concurrent
producers must wait for the entry to be released by some consumer (which
may be locked up as illustrated above).
While it would be nice if producers could simply call kmalloc() and
append their instance of struct other_info to a list, we are very
limited in this code path: since KCSAN can instrument the allocators
themselves, calling kmalloc() could lead to deadlock or corrupted
allocator state.
Since producers of the struct other_info will always succeed at
try_consume_watchpoint(), preceding the call into kcsan_report(), we
know that the particular watchpoint slot cannot simply be reused or
consumed by another potential other_info producer. If we move removal of
a watchpoint after reporting (by the consumer of struct other_info), we
can see a consumed watchpoint as a held lock on elements of other_info,
if we create a one-to-one mapping of a watchpoint to an other_info
element.
Therefore, the simplest solution is to create an array of struct
other_info that is as large as the watchpoints array in core.c, and pass
the watchpoint index to kcsan_report() for producers and consumers, and
change watchpoints to be removed after reporting is done.
With a default config on a 64-bit system, the array other_infos consumes
~37KiB. For most systems today this is not a problem. On smaller memory
constrained systems, the config value CONFIG_KCSAN_NUM_WATCHPOINTS can
be reduced appropriately.
Overall, this change is a simplification of the prepare_report() code,
and makes some of the checks (such as checking if at least one access is
a write) redundant.
Tested:
$ tools/testing/selftests/rcutorture/bin/kvm.sh \
--cpus 12 --duration 10 --kconfig "CONFIG_DEBUG_INFO=y \
CONFIG_KCSAN=y CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=n \
CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n \
CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y \
CONFIG_KCSAN_INTERRUPT_WATCHER=y CONFIG_PROVE_LOCKING=y" \
--configs TREE03
=> No longer hangs and runs to completion as expected.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-18 20:38:45 +03:00
|
|
|
/*
|
|
|
|
* Remove watchpoint; must be after reporting, since the slot may be
|
|
|
|
* reused after this point.
|
|
|
|
*/
|
|
|
|
remove_watchpoint(watchpoint);
|
2020-08-10 11:06:25 +03:00
|
|
|
atomic_long_dec(&kcsan_counters[KCSAN_COUNTER_USED_WATCHPOINTS]);
|
2019-11-14 21:02:54 +03:00
|
|
|
out_unlock:
|
2020-02-22 01:02:09 +03:00
|
|
|
if (!kcsan_interrupt_watcher)
|
2020-06-24 14:32:46 +03:00
|
|
|
local_irq_restore(irq_flags);
|
2020-07-29 14:09:16 +03:00
|
|
|
kcsan_restore_irqtrace(current);
|
2019-11-14 21:02:54 +03:00
|
|
|
out:
|
|
|
|
user_access_restore(ua_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void check_access(const volatile void *ptr, size_t size,
|
|
|
|
int type)
|
|
|
|
{
|
|
|
|
const bool is_write = (type & KCSAN_ACCESS_WRITE) != 0;
|
|
|
|
atomic_long_t *watchpoint;
|
|
|
|
long encoded_watchpoint;
|
|
|
|
|
2020-02-05 13:14:19 +03:00
|
|
|
/*
|
|
|
|
* Do nothing for 0 sized check; this comparison will be optimized out
|
|
|
|
* for constant sized instrumentation (__tsan_{read,write}N).
|
|
|
|
*/
|
|
|
|
if (unlikely(size == 0))
|
|
|
|
return;
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
/*
|
|
|
|
* Avoid user_access_save in fast-path: find_watchpoint is safe without
|
|
|
|
* user_access_save, as the address that ptr points to is only used to
|
|
|
|
* check if a watchpoint exists; ptr is never dereferenced.
|
|
|
|
*/
|
|
|
|
watchpoint = find_watchpoint((unsigned long)ptr, size, !is_write,
|
|
|
|
&encoded_watchpoint);
|
|
|
|
/*
|
|
|
|
* It is safe to check kcsan_is_enabled() after find_watchpoint in the
|
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 18:46:24 +03:00
|
|
|
* slow-path, as long as no state changes that cause a race to be
|
2019-11-14 21:02:54 +03:00
|
|
|
* detected and reported have occurred until kcsan_is_enabled() is
|
|
|
|
* checked.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (unlikely(watchpoint != NULL))
|
2020-01-10 21:48:33 +03:00
|
|
|
kcsan_found_watchpoint(ptr, size, type, watchpoint,
|
2019-11-14 21:02:54 +03:00
|
|
|
encoded_watchpoint);
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
else {
|
|
|
|
struct kcsan_ctx *ctx = get_ctx(); /* Call only once in fast-path. */
|
|
|
|
|
|
|
|
if (unlikely(should_watch(ptr, size, type, ctx)))
|
|
|
|
kcsan_setup_watchpoint(ptr, size, type);
|
|
|
|
else if (unlikely(ctx->scoped_accesses.prev))
|
|
|
|
kcsan_check_scoped_accesses();
|
|
|
|
}
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* === Public interface ===================================================== */
|
|
|
|
|
|
|
|
void __init kcsan_init(void)
|
|
|
|
{
|
2020-11-24 14:02:09 +03:00
|
|
|
int cpu;
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
BUG_ON(!in_task());
|
|
|
|
|
2020-11-24 14:02:09 +03:00
|
|
|
for_each_possible_cpu(cpu)
|
|
|
|
per_cpu(kcsan_rand_state, cpu) = (u32)get_cycles();
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We are in the init task, and no other tasks should be running;
|
|
|
|
* WRITE_ONCE without memory barrier is sufficient.
|
|
|
|
*/
|
2020-07-31 11:17:22 +03:00
|
|
|
if (kcsan_early_enable) {
|
|
|
|
pr_info("enabled early\n");
|
2019-11-14 21:02:54 +03:00
|
|
|
WRITE_ONCE(kcsan_enabled, true);
|
2020-07-31 11:17:22 +03:00
|
|
|
}
|
2019-11-14 21:02:54 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* === Exported interface =================================================== */
|
|
|
|
|
|
|
|
void kcsan_disable_current(void)
|
|
|
|
{
|
|
|
|
++get_ctx()->disable_count;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_disable_current);
|
|
|
|
|
|
|
|
void kcsan_enable_current(void)
|
|
|
|
{
|
|
|
|
if (get_ctx()->disable_count-- == 0) {
|
|
|
|
/*
|
|
|
|
* Warn if kcsan_enable_current() calls are unbalanced with
|
|
|
|
* kcsan_disable_current() calls, which causes disable_count to
|
|
|
|
* become negative and should not happen.
|
|
|
|
*/
|
|
|
|
kcsan_disable_current(); /* restore to 0, KCSAN still enabled */
|
|
|
|
kcsan_disable_current(); /* disable to generate warning */
|
|
|
|
WARN(1, "Unbalanced %s()", __func__);
|
|
|
|
kcsan_enable_current();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_enable_current);
|
|
|
|
|
2020-04-24 18:47:29 +03:00
|
|
|
void kcsan_enable_current_nowarn(void)
|
|
|
|
{
|
|
|
|
if (get_ctx()->disable_count-- == 0)
|
|
|
|
kcsan_disable_current();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_enable_current_nowarn);
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
void kcsan_nestable_atomic_begin(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Do *not* check and warn if we are in a flat atomic region: nestable
|
|
|
|
* and flat atomic regions are independent from each other.
|
|
|
|
* See include/linux/kcsan.h: struct kcsan_ctx comments for more
|
|
|
|
* comments.
|
|
|
|
*/
|
|
|
|
|
|
|
|
++get_ctx()->atomic_nest_count;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_nestable_atomic_begin);
|
|
|
|
|
|
|
|
void kcsan_nestable_atomic_end(void)
|
|
|
|
{
|
|
|
|
if (get_ctx()->atomic_nest_count-- == 0) {
|
|
|
|
/*
|
|
|
|
* Warn if kcsan_nestable_atomic_end() calls are unbalanced with
|
|
|
|
* kcsan_nestable_atomic_begin() calls, which causes
|
|
|
|
* atomic_nest_count to become negative and should not happen.
|
|
|
|
*/
|
|
|
|
kcsan_nestable_atomic_begin(); /* restore to 0 */
|
|
|
|
kcsan_disable_current(); /* disable to generate warning */
|
|
|
|
WARN(1, "Unbalanced %s()", __func__);
|
|
|
|
kcsan_enable_current();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_nestable_atomic_end);
|
|
|
|
|
|
|
|
void kcsan_flat_atomic_begin(void)
|
|
|
|
{
|
|
|
|
get_ctx()->in_flat_atomic = true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_flat_atomic_begin);
|
|
|
|
|
|
|
|
void kcsan_flat_atomic_end(void)
|
|
|
|
{
|
|
|
|
get_ctx()->in_flat_atomic = false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_flat_atomic_end);
|
|
|
|
|
|
|
|
void kcsan_atomic_next(int n)
|
|
|
|
{
|
|
|
|
get_ctx()->atomic_next = n;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_atomic_next);
|
|
|
|
|
2020-02-11 19:04:22 +03:00
|
|
|
void kcsan_set_access_mask(unsigned long mask)
|
|
|
|
{
|
|
|
|
get_ctx()->access_mask = mask;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_set_access_mask);
|
|
|
|
|
kcsan: Add support for scoped accesses
This adds support for scoped accesses, where the memory range is checked
for the duration of the scope. The feature is implemented by inserting
the relevant access information into a list of scoped accesses for
the current execution context, which are then checked (until removed)
on every call (through instrumentation) into the KCSAN runtime.
An alternative, more complex, implementation could set up a watchpoint for
the scoped access, and keep the watchpoint set up. This, however, would
require first exposing a handle to the watchpoint, as well as dealing
with cases such as accesses by the same thread while the watchpoint is
still set up (and several more cases). It is also doubtful if this would
provide any benefit, since the majority of delay where the watchpoint
is set up is likely due to the injected delays by KCSAN. Therefore,
the implementation in this patch is simpler and avoids hurting KCSAN's
main use-case (normal data race detection); it also implicitly increases
scoped-access race-detection-ability due to increased probability of
setting up watchpoints by repeatedly calling __kcsan_check_access()
throughout the scope of the access.
The implementation required adding an additional conditional branch to
the fast-path. However, the microbenchmark showed a *speedup* of ~5%
on the fast-path. This appears to be due to subtly improved codegen by
GCC from moving get_ctx() and associated load of preempt_count earlier.
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-03-25 19:41:56 +03:00
|
|
|
struct kcsan_scoped_access *
|
|
|
|
kcsan_begin_scoped_access(const volatile void *ptr, size_t size, int type,
|
|
|
|
struct kcsan_scoped_access *sa)
|
|
|
|
{
|
|
|
|
struct kcsan_ctx *ctx = get_ctx();
|
|
|
|
|
|
|
|
__kcsan_check_access(ptr, size, type);
|
|
|
|
|
|
|
|
ctx->disable_count++; /* Disable KCSAN, in case list debugging is on. */
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&sa->list);
|
|
|
|
sa->ptr = ptr;
|
|
|
|
sa->size = size;
|
|
|
|
sa->type = type;
|
|
|
|
|
|
|
|
if (!ctx->scoped_accesses.prev) /* Lazy initialize list head. */
|
|
|
|
INIT_LIST_HEAD(&ctx->scoped_accesses);
|
|
|
|
list_add(&sa->list, &ctx->scoped_accesses);
|
|
|
|
|
|
|
|
ctx->disable_count--;
|
|
|
|
return sa;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_begin_scoped_access);
|
|
|
|
|
|
|
|
void kcsan_end_scoped_access(struct kcsan_scoped_access *sa)
|
|
|
|
{
|
|
|
|
struct kcsan_ctx *ctx = get_ctx();
|
|
|
|
|
|
|
|
if (WARN(!ctx->scoped_accesses.prev, "Unbalanced %s()?", __func__))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ctx->disable_count++; /* Disable KCSAN, in case list debugging is on. */
|
|
|
|
|
|
|
|
list_del(&sa->list);
|
|
|
|
if (list_empty(&ctx->scoped_accesses))
|
|
|
|
/*
|
|
|
|
* Ensure we do not enter kcsan_check_scoped_accesses()
|
|
|
|
* slow-path if unnecessary, and avoids requiring list_empty()
|
|
|
|
* in the fast-path (to avoid a READ_ONCE() and potential
|
|
|
|
* uaccess warning).
|
|
|
|
*/
|
|
|
|
ctx->scoped_accesses.prev = NULL;
|
|
|
|
|
|
|
|
ctx->disable_count--;
|
|
|
|
|
|
|
|
__kcsan_check_access(sa->ptr, sa->size, sa->type);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kcsan_end_scoped_access);
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
void __kcsan_check_access(const volatile void *ptr, size_t size, int type)
|
|
|
|
{
|
|
|
|
check_access(ptr, size, type);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__kcsan_check_access);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* KCSAN uses the same instrumentation that is emitted by supported compilers
|
|
|
|
* for ThreadSanitizer (TSAN).
|
|
|
|
*
|
|
|
|
* When enabled, the compiler emits instrumentation calls (the functions
|
|
|
|
* prefixed with "__tsan" below) for all loads and stores that it generated;
|
|
|
|
* inline asm is not instrumented.
|
|
|
|
*
|
|
|
|
* Note that, not all supported compiler versions distinguish aligned/unaligned
|
|
|
|
* accesses, but e.g. recent versions of Clang do. We simply alias the unaligned
|
|
|
|
* version to the generic version, which can handle both.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define DEFINE_TSAN_READ_WRITE(size) \
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_read##size(void *ptr); \
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_read##size(void *ptr) \
|
|
|
|
{ \
|
|
|
|
check_access(ptr, size, 0); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_read##size); \
|
|
|
|
void __tsan_unaligned_read##size(void *ptr) \
|
|
|
|
__alias(__tsan_read##size); \
|
|
|
|
EXPORT_SYMBOL(__tsan_unaligned_read##size); \
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_write##size(void *ptr); \
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_write##size(void *ptr) \
|
|
|
|
{ \
|
|
|
|
check_access(ptr, size, KCSAN_ACCESS_WRITE); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_write##size); \
|
|
|
|
void __tsan_unaligned_write##size(void *ptr) \
|
|
|
|
__alias(__tsan_write##size); \
|
kcsan: Support compounded read-write instrumentation
Add support for compounded read-write instrumentation if supported by
the compiler. Adds the necessary instrumentation functions, and a new
type which is used to generate a more descriptive report.
Furthermore, such compounded memory access instrumentation is excluded
from the "assume aligned writes up to word size are atomic" rule,
because we cannot assume that the compiler emits code that is atomic for
compound ops.
LLVM/Clang added support for the feature in:
https://github.com/llvm/llvm-project/commit/785d41a261d136b64ab6c15c5d35f2adc5ad53e3
The new instrumentation is emitted for sets of memory accesses in the
same basic block to the same address with at least one read appearing
before a write. These typically result from compound operations such as
++, --, +=, -=, |=, &=, etc. but also equivalent forms such as "var =
var + 1". Where the compiler determines that it is equivalent to emit a
call to a single __tsan_read_write instead of separate __tsan_read and
__tsan_write, we can then benefit from improved performance and better
reporting for such access patterns.
The new reports now show that the ops are both reads and writes, for
example:
read-write to 0xffffffff90548a38 of 8 bytes by task 143 on cpu 3:
test_kernel_rmw_array+0x45/0xa0
access_thread+0x71/0xb0
kthread+0x21e/0x240
ret_from_fork+0x22/0x30
read-write to 0xffffffff90548a38 of 8 bytes by task 144 on cpu 2:
test_kernel_rmw_array+0x45/0xa0
access_thread+0x71/0xb0
kthread+0x21e/0x240
ret_from_fork+0x22/0x30
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-07-24 10:00:01 +03:00
|
|
|
EXPORT_SYMBOL(__tsan_unaligned_write##size); \
|
|
|
|
void __tsan_read_write##size(void *ptr); \
|
|
|
|
void __tsan_read_write##size(void *ptr) \
|
|
|
|
{ \
|
|
|
|
check_access(ptr, size, \
|
|
|
|
KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_read_write##size); \
|
|
|
|
void __tsan_unaligned_read_write##size(void *ptr) \
|
|
|
|
__alias(__tsan_read_write##size); \
|
|
|
|
EXPORT_SYMBOL(__tsan_unaligned_read_write##size)
|
2019-11-14 21:02:54 +03:00
|
|
|
|
|
|
|
DEFINE_TSAN_READ_WRITE(1);
|
|
|
|
DEFINE_TSAN_READ_WRITE(2);
|
|
|
|
DEFINE_TSAN_READ_WRITE(4);
|
|
|
|
DEFINE_TSAN_READ_WRITE(8);
|
|
|
|
DEFINE_TSAN_READ_WRITE(16);
|
|
|
|
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_read_range(void *ptr, size_t size);
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_read_range(void *ptr, size_t size)
|
|
|
|
{
|
|
|
|
check_access(ptr, size, 0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tsan_read_range);
|
|
|
|
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_write_range(void *ptr, size_t size);
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_write_range(void *ptr, size_t size)
|
|
|
|
{
|
|
|
|
check_access(ptr, size, KCSAN_ACCESS_WRITE);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tsan_write_range);
|
|
|
|
|
2020-05-21 17:20:39 +03:00
|
|
|
/*
|
|
|
|
* Use of explicit volatile is generally disallowed [1], however, volatile is
|
|
|
|
* still used in various concurrent context, whether in low-level
|
|
|
|
* synchronization primitives or for legacy reasons.
|
|
|
|
* [1] https://lwn.net/Articles/233479/
|
|
|
|
*
|
|
|
|
* We only consider volatile accesses atomic if they are aligned and would pass
|
|
|
|
* the size-check of compiletime_assert_rwonce_type().
|
|
|
|
*/
|
|
|
|
#define DEFINE_TSAN_VOLATILE_READ_WRITE(size) \
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_volatile_read##size(void *ptr); \
|
2020-05-21 17:20:39 +03:00
|
|
|
void __tsan_volatile_read##size(void *ptr) \
|
|
|
|
{ \
|
|
|
|
const bool is_atomic = size <= sizeof(long long) && \
|
|
|
|
IS_ALIGNED((unsigned long)ptr, size); \
|
|
|
|
if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic) \
|
|
|
|
return; \
|
|
|
|
check_access(ptr, size, is_atomic ? KCSAN_ACCESS_ATOMIC : 0); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_volatile_read##size); \
|
|
|
|
void __tsan_unaligned_volatile_read##size(void *ptr) \
|
|
|
|
__alias(__tsan_volatile_read##size); \
|
|
|
|
EXPORT_SYMBOL(__tsan_unaligned_volatile_read##size); \
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_volatile_write##size(void *ptr); \
|
2020-05-21 17:20:39 +03:00
|
|
|
void __tsan_volatile_write##size(void *ptr) \
|
|
|
|
{ \
|
|
|
|
const bool is_atomic = size <= sizeof(long long) && \
|
|
|
|
IS_ALIGNED((unsigned long)ptr, size); \
|
|
|
|
if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic) \
|
|
|
|
return; \
|
|
|
|
check_access(ptr, size, \
|
|
|
|
KCSAN_ACCESS_WRITE | \
|
|
|
|
(is_atomic ? KCSAN_ACCESS_ATOMIC : 0)); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_volatile_write##size); \
|
|
|
|
void __tsan_unaligned_volatile_write##size(void *ptr) \
|
|
|
|
__alias(__tsan_volatile_write##size); \
|
|
|
|
EXPORT_SYMBOL(__tsan_unaligned_volatile_write##size)
|
|
|
|
|
|
|
|
DEFINE_TSAN_VOLATILE_READ_WRITE(1);
|
|
|
|
DEFINE_TSAN_VOLATILE_READ_WRITE(2);
|
|
|
|
DEFINE_TSAN_VOLATILE_READ_WRITE(4);
|
|
|
|
DEFINE_TSAN_VOLATILE_READ_WRITE(8);
|
|
|
|
DEFINE_TSAN_VOLATILE_READ_WRITE(16);
|
|
|
|
|
2019-11-14 21:02:54 +03:00
|
|
|
/*
|
|
|
|
* The below are not required by KCSAN, but can still be emitted by the
|
|
|
|
* compiler.
|
|
|
|
*/
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_func_entry(void *call_pc);
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_func_entry(void *call_pc)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tsan_func_entry);
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_func_exit(void);
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_func_exit(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tsan_func_exit);
|
2020-06-16 15:36:22 +03:00
|
|
|
void __tsan_init(void);
|
2019-11-14 21:02:54 +03:00
|
|
|
void __tsan_init(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tsan_init);
|
2020-07-03 16:40:29 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Instrumentation for atomic builtins (__atomic_*, __sync_*).
|
|
|
|
*
|
|
|
|
* Normal kernel code _should not_ be using them directly, but some
|
|
|
|
* architectures may implement some or all atomics using the compilers'
|
|
|
|
* builtins.
|
|
|
|
*
|
|
|
|
* Note: If an architecture decides to fully implement atomics using the
|
|
|
|
* builtins, because they are implicitly instrumented by KCSAN (and KASAN,
|
|
|
|
* etc.), implementing the ARCH_ATOMIC interface (to get instrumentation via
|
|
|
|
* atomic-instrumented) is no longer necessary.
|
|
|
|
*
|
|
|
|
* TSAN instrumentation replaces atomic accesses with calls to any of the below
|
|
|
|
* functions, whose job is to also execute the operation itself.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define DEFINE_TSAN_ATOMIC_LOAD_STORE(bits) \
|
|
|
|
u##bits __tsan_atomic##bits##_load(const u##bits *ptr, int memorder); \
|
|
|
|
u##bits __tsan_atomic##bits##_load(const u##bits *ptr, int memorder) \
|
|
|
|
{ \
|
2020-07-24 10:00:04 +03:00
|
|
|
if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) { \
|
|
|
|
check_access(ptr, bits / BITS_PER_BYTE, KCSAN_ACCESS_ATOMIC); \
|
|
|
|
} \
|
2020-07-03 16:40:29 +03:00
|
|
|
return __atomic_load_n(ptr, memorder); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic##bits##_load); \
|
|
|
|
void __tsan_atomic##bits##_store(u##bits *ptr, u##bits v, int memorder); \
|
|
|
|
void __tsan_atomic##bits##_store(u##bits *ptr, u##bits v, int memorder) \
|
|
|
|
{ \
|
2020-07-24 10:00:04 +03:00
|
|
|
if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) { \
|
|
|
|
check_access(ptr, bits / BITS_PER_BYTE, \
|
|
|
|
KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ATOMIC); \
|
|
|
|
} \
|
2020-07-03 16:40:29 +03:00
|
|
|
__atomic_store_n(ptr, v, memorder); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic##bits##_store)
|
|
|
|
|
|
|
|
#define DEFINE_TSAN_ATOMIC_RMW(op, bits, suffix) \
|
|
|
|
u##bits __tsan_atomic##bits##_##op(u##bits *ptr, u##bits v, int memorder); \
|
|
|
|
u##bits __tsan_atomic##bits##_##op(u##bits *ptr, u##bits v, int memorder) \
|
|
|
|
{ \
|
2020-07-24 10:00:04 +03:00
|
|
|
if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) { \
|
|
|
|
check_access(ptr, bits / BITS_PER_BYTE, \
|
|
|
|
KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | \
|
|
|
|
KCSAN_ACCESS_ATOMIC); \
|
|
|
|
} \
|
2020-07-03 16:40:29 +03:00
|
|
|
return __atomic_##op##suffix(ptr, v, memorder); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic##bits##_##op)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: CAS operations are always classified as write, even in case they
|
|
|
|
* fail. We cannot perform check_access() after a write, as it might lead to
|
|
|
|
* false positives, in cases such as:
|
|
|
|
*
|
|
|
|
* T0: __atomic_compare_exchange_n(&p->flag, &old, 1, ...)
|
|
|
|
*
|
|
|
|
* T1: if (__atomic_load_n(&p->flag, ...)) {
|
|
|
|
* modify *p;
|
|
|
|
* p->flag = 0;
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* The only downside is that, if there are 3 threads, with one CAS that
|
|
|
|
* succeeds, another CAS that fails, and an unmarked racing operation, we may
|
|
|
|
* point at the wrong CAS as the source of the race. However, if we assume that
|
|
|
|
* all CAS can succeed in some other execution, the data race is still valid.
|
|
|
|
*/
|
|
|
|
#define DEFINE_TSAN_ATOMIC_CMPXCHG(bits, strength, weak) \
|
|
|
|
int __tsan_atomic##bits##_compare_exchange_##strength(u##bits *ptr, u##bits *exp, \
|
|
|
|
u##bits val, int mo, int fail_mo); \
|
|
|
|
int __tsan_atomic##bits##_compare_exchange_##strength(u##bits *ptr, u##bits *exp, \
|
|
|
|
u##bits val, int mo, int fail_mo) \
|
|
|
|
{ \
|
2020-07-24 10:00:04 +03:00
|
|
|
if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) { \
|
|
|
|
check_access(ptr, bits / BITS_PER_BYTE, \
|
|
|
|
KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | \
|
|
|
|
KCSAN_ACCESS_ATOMIC); \
|
|
|
|
} \
|
2020-07-03 16:40:29 +03:00
|
|
|
return __atomic_compare_exchange_n(ptr, exp, val, weak, mo, fail_mo); \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic##bits##_compare_exchange_##strength)
|
|
|
|
|
|
|
|
#define DEFINE_TSAN_ATOMIC_CMPXCHG_VAL(bits) \
|
|
|
|
u##bits __tsan_atomic##bits##_compare_exchange_val(u##bits *ptr, u##bits exp, u##bits val, \
|
|
|
|
int mo, int fail_mo); \
|
|
|
|
u##bits __tsan_atomic##bits##_compare_exchange_val(u##bits *ptr, u##bits exp, u##bits val, \
|
|
|
|
int mo, int fail_mo) \
|
|
|
|
{ \
|
2020-07-24 10:00:04 +03:00
|
|
|
if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) { \
|
|
|
|
check_access(ptr, bits / BITS_PER_BYTE, \
|
|
|
|
KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | \
|
|
|
|
KCSAN_ACCESS_ATOMIC); \
|
|
|
|
} \
|
2020-07-03 16:40:29 +03:00
|
|
|
__atomic_compare_exchange_n(ptr, &exp, val, 0, mo, fail_mo); \
|
|
|
|
return exp; \
|
|
|
|
} \
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic##bits##_compare_exchange_val)
|
|
|
|
|
|
|
|
#define DEFINE_TSAN_ATOMIC_OPS(bits) \
|
|
|
|
DEFINE_TSAN_ATOMIC_LOAD_STORE(bits); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(exchange, bits, _n); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(fetch_add, bits, ); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(fetch_sub, bits, ); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(fetch_and, bits, ); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(fetch_or, bits, ); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(fetch_xor, bits, ); \
|
|
|
|
DEFINE_TSAN_ATOMIC_RMW(fetch_nand, bits, ); \
|
|
|
|
DEFINE_TSAN_ATOMIC_CMPXCHG(bits, strong, 0); \
|
|
|
|
DEFINE_TSAN_ATOMIC_CMPXCHG(bits, weak, 1); \
|
|
|
|
DEFINE_TSAN_ATOMIC_CMPXCHG_VAL(bits)
|
|
|
|
|
|
|
|
DEFINE_TSAN_ATOMIC_OPS(8);
|
|
|
|
DEFINE_TSAN_ATOMIC_OPS(16);
|
|
|
|
DEFINE_TSAN_ATOMIC_OPS(32);
|
|
|
|
DEFINE_TSAN_ATOMIC_OPS(64);
|
|
|
|
|
|
|
|
void __tsan_atomic_thread_fence(int memorder);
|
|
|
|
void __tsan_atomic_thread_fence(int memorder)
|
|
|
|
{
|
|
|
|
__atomic_thread_fence(memorder);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic_thread_fence);
|
|
|
|
|
|
|
|
void __tsan_atomic_signal_fence(int memorder);
|
|
|
|
void __tsan_atomic_signal_fence(int memorder) { }
|
|
|
|
EXPORT_SYMBOL(__tsan_atomic_signal_fence);
|