2019-11-15 02:02:54 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2021-01-16 01:09:53 +08:00
|
|
|
/*
|
|
|
|
* KCSAN access checks and modifiers. These can be used to explicitly check
|
|
|
|
* uninstrumented accesses, or change KCSAN checking behaviour of accesses.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2019, Google LLC.
|
|
|
|
*/
|
2019-11-15 02:02:54 +08:00
|
|
|
|
|
|
|
#ifndef _LINUX_KCSAN_CHECKS_H
|
|
|
|
#define _LINUX_KCSAN_CHECKS_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-26 00:41:56 +08:00
|
|
|
/* Note: Only include what is already included by compiler.h. */
|
|
|
|
#include <linux/compiler_attributes.h>
|
2019-11-15 02:02:54 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
|
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 15:00:01 +08:00
|
|
|
/* Access types -- if KCSAN_ACCESS_WRITE is not set, the access is a read. */
|
|
|
|
#define KCSAN_ACCESS_WRITE (1 << 0) /* Access is a write. */
|
|
|
|
#define KCSAN_ACCESS_COMPOUND (1 << 1) /* Compounded read-write instrumentation. */
|
|
|
|
#define KCSAN_ACCESS_ATOMIC (1 << 2) /* Access is atomic. */
|
|
|
|
/* The following are special, and never due to compiler instrumentation. */
|
|
|
|
#define KCSAN_ACCESS_ASSERT (1 << 3) /* Access is an assertion. */
|
|
|
|
#define KCSAN_ACCESS_SCOPED (1 << 4) /* Access is a scoped access. */
|
2019-11-15 02:02:54 +08:00
|
|
|
|
|
|
|
/*
|
2019-11-20 17:41:43 +08:00
|
|
|
* __kcsan_*: Always calls into the runtime when KCSAN is enabled. This may be used
|
2019-11-15 02:02:54 +08:00
|
|
|
* even in compilation units that selectively disable KCSAN, but must use KCSAN
|
2019-11-20 17:41:43 +08:00
|
|
|
* to validate access to an address. Never use these in header files!
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#ifdef CONFIG_KCSAN
|
|
|
|
/**
|
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 23:46:24 +08:00
|
|
|
* __kcsan_check_access - check generic access for races
|
2019-11-15 02:02:54 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
|
|
|
* @type: access type modifier
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
void __kcsan_check_access(const volatile void *ptr, size_t size, int type);
|
|
|
|
|
2020-04-01 03:32:32 +08:00
|
|
|
/**
|
|
|
|
* kcsan_disable_current - disable KCSAN for the current context
|
|
|
|
*
|
|
|
|
* Supports nesting.
|
|
|
|
*/
|
|
|
|
void kcsan_disable_current(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_enable_current - re-enable KCSAN for the current context
|
|
|
|
*
|
|
|
|
* Supports nesting.
|
|
|
|
*/
|
|
|
|
void kcsan_enable_current(void);
|
2020-04-24 23:47:29 +08:00
|
|
|
void kcsan_enable_current_nowarn(void); /* Safe in uaccess regions. */
|
2020-04-01 03:32:32 +08:00
|
|
|
|
2020-02-12 00:04:19 +08:00
|
|
|
/**
|
|
|
|
* kcsan_nestable_atomic_begin - begin nestable atomic region
|
|
|
|
*
|
|
|
|
* Accesses within the atomic region may appear to race with other accesses but
|
|
|
|
* should be considered atomic.
|
|
|
|
*/
|
|
|
|
void kcsan_nestable_atomic_begin(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_nestable_atomic_end - end nestable atomic region
|
|
|
|
*/
|
|
|
|
void kcsan_nestable_atomic_end(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_flat_atomic_begin - begin flat atomic region
|
|
|
|
*
|
|
|
|
* Accesses within the atomic region may appear to race with other accesses but
|
|
|
|
* should be considered atomic.
|
|
|
|
*/
|
|
|
|
void kcsan_flat_atomic_begin(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_flat_atomic_end - end flat atomic region
|
|
|
|
*/
|
|
|
|
void kcsan_flat_atomic_end(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_atomic_next - consider following accesses as atomic
|
|
|
|
*
|
|
|
|
* Force treating the next n memory accesses for the current context as atomic
|
|
|
|
* operations.
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @n: number of following memory accesses to treat as atomic.
|
2020-02-12 00:04:19 +08:00
|
|
|
*/
|
|
|
|
void kcsan_atomic_next(int n);
|
|
|
|
|
2020-02-12 00:04:22 +08:00
|
|
|
/**
|
|
|
|
* kcsan_set_access_mask - set access mask
|
|
|
|
*
|
|
|
|
* Set the access mask for all accesses for the current context if non-zero.
|
|
|
|
* Only value changes to bits set in the mask will be reported.
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @mask: bitmask
|
2020-02-12 00:04:22 +08:00
|
|
|
*/
|
|
|
|
void kcsan_set_access_mask(unsigned long 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-26 00:41:56 +08:00
|
|
|
/* Scoped access information. */
|
|
|
|
struct kcsan_scoped_access {
|
|
|
|
struct list_head list;
|
2021-08-09 19:25:13 +08:00
|
|
|
/* Access information. */
|
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-26 00:41:56 +08:00
|
|
|
const volatile void *ptr;
|
|
|
|
size_t size;
|
|
|
|
int type;
|
2021-08-09 19:25:13 +08:00
|
|
|
/* Location where scoped access was set up. */
|
|
|
|
unsigned long ip;
|
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-26 00:41:56 +08:00
|
|
|
};
|
|
|
|
/*
|
|
|
|
* Automatically call kcsan_end_scoped_access() when kcsan_scoped_access goes
|
|
|
|
* out of scope; relies on attribute "cleanup", which is supported by all
|
|
|
|
* compilers that support KCSAN.
|
|
|
|
*/
|
|
|
|
#define __kcsan_cleanup_scoped \
|
|
|
|
__maybe_unused __attribute__((__cleanup__(kcsan_end_scoped_access)))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_begin_scoped_access - begin scoped access
|
|
|
|
*
|
|
|
|
* Begin scoped access and initialize @sa, which will cause KCSAN to
|
|
|
|
* continuously check the memory range in the current thread until
|
|
|
|
* kcsan_end_scoped_access() is called for @sa.
|
|
|
|
*
|
|
|
|
* Scoped accesses are implemented by appending @sa to an internal list for the
|
|
|
|
* current execution context, and then checked on every call into the KCSAN
|
|
|
|
* runtime.
|
|
|
|
*
|
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
|
|
|
* @type: access type modifier
|
|
|
|
* @sa: struct kcsan_scoped_access to use for the scope of the access
|
|
|
|
*/
|
|
|
|
struct kcsan_scoped_access *
|
|
|
|
kcsan_begin_scoped_access(const volatile void *ptr, size_t size, int type,
|
|
|
|
struct kcsan_scoped_access *sa);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kcsan_end_scoped_access - end scoped access
|
|
|
|
*
|
|
|
|
* End a scoped access, which will stop KCSAN checking the memory range.
|
|
|
|
* Requires that kcsan_begin_scoped_access() was previously called once for @sa.
|
|
|
|
*
|
|
|
|
* @sa: a previously initialized struct kcsan_scoped_access
|
|
|
|
*/
|
|
|
|
void kcsan_end_scoped_access(struct kcsan_scoped_access *sa);
|
|
|
|
|
|
|
|
|
2020-02-12 00:04:19 +08:00
|
|
|
#else /* CONFIG_KCSAN */
|
|
|
|
|
2019-11-15 02:02:54 +08:00
|
|
|
static inline void __kcsan_check_access(const volatile void *ptr, size_t size,
|
|
|
|
int type) { }
|
2020-02-12 00:04:19 +08:00
|
|
|
|
2020-04-01 03:32:32 +08:00
|
|
|
static inline void kcsan_disable_current(void) { }
|
|
|
|
static inline void kcsan_enable_current(void) { }
|
2020-04-24 23:47:29 +08:00
|
|
|
static inline void kcsan_enable_current_nowarn(void) { }
|
2020-02-12 00:04:19 +08:00
|
|
|
static inline void kcsan_nestable_atomic_begin(void) { }
|
|
|
|
static inline void kcsan_nestable_atomic_end(void) { }
|
|
|
|
static inline void kcsan_flat_atomic_begin(void) { }
|
|
|
|
static inline void kcsan_flat_atomic_end(void) { }
|
|
|
|
static inline void kcsan_atomic_next(int n) { }
|
2020-02-12 00:04:22 +08:00
|
|
|
static inline void kcsan_set_access_mask(unsigned long mask) { }
|
2020-02-12 00:04:19 +08:00
|
|
|
|
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-26 00:41:56 +08:00
|
|
|
struct kcsan_scoped_access { };
|
|
|
|
#define __kcsan_cleanup_scoped __maybe_unused
|
|
|
|
static inline struct kcsan_scoped_access *
|
|
|
|
kcsan_begin_scoped_access(const volatile void *ptr, size_t size, int type,
|
|
|
|
struct kcsan_scoped_access *sa) { return sa; }
|
|
|
|
static inline void kcsan_end_scoped_access(struct kcsan_scoped_access *sa) { }
|
|
|
|
|
2020-02-12 00:04:19 +08:00
|
|
|
#endif /* CONFIG_KCSAN */
|
2019-11-15 02:02:54 +08:00
|
|
|
|
2020-04-24 23:47:29 +08:00
|
|
|
#ifdef __SANITIZE_THREAD__
|
2019-11-15 02:02:54 +08:00
|
|
|
/*
|
2020-04-24 23:47:29 +08:00
|
|
|
* Only calls into the runtime when the particular compilation unit has KCSAN
|
|
|
|
* instrumentation enabled. May be used in header files.
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#define kcsan_check_access __kcsan_check_access
|
2020-04-24 23:47:29 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only use these to disable KCSAN for accesses in the current compilation unit;
|
|
|
|
* calls into libraries may still perform KCSAN checks.
|
|
|
|
*/
|
|
|
|
#define __kcsan_disable_current kcsan_disable_current
|
|
|
|
#define __kcsan_enable_current kcsan_enable_current_nowarn
|
2019-11-15 02:02:54 +08:00
|
|
|
#else
|
|
|
|
static inline void kcsan_check_access(const volatile void *ptr, size_t size,
|
|
|
|
int type) { }
|
2020-04-24 23:47:29 +08:00
|
|
|
static inline void __kcsan_enable_current(void) { }
|
|
|
|
static inline void __kcsan_disable_current(void) { }
|
2019-11-15 02:02:54 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/**
|
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 23:46:24 +08:00
|
|
|
* __kcsan_check_read - check regular read access for races
|
2019-11-15 02:02:54 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#define __kcsan_check_read(ptr, size) __kcsan_check_access(ptr, size, 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 23:46:24 +08:00
|
|
|
* __kcsan_check_write - check regular write access for races
|
2019-11-15 02:02:54 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#define __kcsan_check_write(ptr, size) \
|
|
|
|
__kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE)
|
|
|
|
|
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 15:00:01 +08:00
|
|
|
/**
|
|
|
|
* __kcsan_check_read_write - check regular read-write access for races
|
|
|
|
*
|
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
|
|
|
*/
|
|
|
|
#define __kcsan_check_read_write(ptr, size) \
|
|
|
|
__kcsan_check_access(ptr, size, KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE)
|
|
|
|
|
2019-11-15 02:02:54 +08: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 23:46:24 +08:00
|
|
|
* kcsan_check_read - check regular read access for races
|
2019-11-15 02:02:54 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#define kcsan_check_read(ptr, size) kcsan_check_access(ptr, size, 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 23:46:24 +08:00
|
|
|
* kcsan_check_write - check regular write access for races
|
2019-11-15 02:02:54 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#define kcsan_check_write(ptr, size) \
|
|
|
|
kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE)
|
|
|
|
|
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 15:00:01 +08:00
|
|
|
/**
|
|
|
|
* kcsan_check_read_write - check regular read-write access for races
|
|
|
|
*
|
|
|
|
* @ptr: address of access
|
|
|
|
* @size: size of access
|
|
|
|
*/
|
|
|
|
#define kcsan_check_read_write(ptr, size) \
|
|
|
|
kcsan_check_access(ptr, size, KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE)
|
|
|
|
|
2019-11-15 02:02:54 +08:00
|
|
|
/*
|
2019-11-20 17:41:43 +08:00
|
|
|
* Check for atomic accesses: if atomic accesses are not ignored, this simply
|
|
|
|
* aliases to kcsan_check_access(), otherwise becomes a no-op.
|
2019-11-15 02:02:54 +08:00
|
|
|
*/
|
|
|
|
#ifdef CONFIG_KCSAN_IGNORE_ATOMICS
|
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 15:00:01 +08:00
|
|
|
#define kcsan_check_atomic_read(...) do { } while (0)
|
|
|
|
#define kcsan_check_atomic_write(...) do { } while (0)
|
|
|
|
#define kcsan_check_atomic_read_write(...) do { } while (0)
|
2019-11-15 02:02:54 +08:00
|
|
|
#else
|
|
|
|
#define kcsan_check_atomic_read(ptr, size) \
|
|
|
|
kcsan_check_access(ptr, size, KCSAN_ACCESS_ATOMIC)
|
|
|
|
#define kcsan_check_atomic_write(ptr, size) \
|
|
|
|
kcsan_check_access(ptr, size, KCSAN_ACCESS_ATOMIC | KCSAN_ACCESS_WRITE)
|
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 15:00:01 +08:00
|
|
|
#define kcsan_check_atomic_read_write(ptr, size) \
|
|
|
|
kcsan_check_access(ptr, size, KCSAN_ACCESS_ATOMIC | KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND)
|
2019-11-15 02:02:54 +08:00
|
|
|
#endif
|
|
|
|
|
2020-02-06 23:46:25 +08:00
|
|
|
/**
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* ASSERT_EXCLUSIVE_WRITER - assert no concurrent writes to @var
|
2020-02-06 23:46:25 +08:00
|
|
|
*
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* Assert that there are no concurrent writes to @var; other readers are
|
2020-02-06 23:46:25 +08:00
|
|
|
* allowed. This assertion can be used to specify properties of concurrent code,
|
|
|
|
* where violation cannot be detected as a normal data race.
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* For example, if we only have a single writer, but multiple concurrent
|
|
|
|
* readers, to avoid data races, all these accesses must be marked; even
|
|
|
|
* concurrent marked writes racing with the single writer are bugs.
|
|
|
|
* Unfortunately, due to being marked, they are no longer data races. For cases
|
|
|
|
* like these, we can use the macro as follows:
|
2020-02-06 23:46:25 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* .. code-block:: c
|
|
|
|
*
|
|
|
|
* void writer(void) {
|
|
|
|
* spin_lock(&update_foo_lock);
|
|
|
|
* ASSERT_EXCLUSIVE_WRITER(shared_foo);
|
|
|
|
* WRITE_ONCE(shared_foo, ...);
|
|
|
|
* spin_unlock(&update_foo_lock);
|
|
|
|
* }
|
|
|
|
* void reader(void) {
|
|
|
|
* // update_foo_lock does not need to be held!
|
|
|
|
* ... = READ_ONCE(shared_foo);
|
|
|
|
* }
|
|
|
|
*
|
2020-03-26 00:41:58 +08:00
|
|
|
* Note: ASSERT_EXCLUSIVE_WRITER_SCOPED(), if applicable, performs more thorough
|
|
|
|
* checking if a clear scope where no concurrent writes are expected exists.
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @var: variable to assert on
|
2020-02-06 23:46:25 +08:00
|
|
|
*/
|
|
|
|
#define ASSERT_EXCLUSIVE_WRITER(var) \
|
|
|
|
__kcsan_check_access(&(var), sizeof(var), KCSAN_ACCESS_ASSERT)
|
|
|
|
|
2020-03-26 00:41:58 +08:00
|
|
|
/*
|
|
|
|
* Helper macros for implementation of for ASSERT_EXCLUSIVE_*_SCOPED(). @id is
|
|
|
|
* expected to be unique for the scope in which instances of kcsan_scoped_access
|
|
|
|
* are declared.
|
|
|
|
*/
|
|
|
|
#define __kcsan_scoped_name(c, suffix) __kcsan_scoped_##c##suffix
|
|
|
|
#define __ASSERT_EXCLUSIVE_SCOPED(var, type, id) \
|
|
|
|
struct kcsan_scoped_access __kcsan_scoped_name(id, _) \
|
|
|
|
__kcsan_cleanup_scoped; \
|
|
|
|
struct kcsan_scoped_access *__kcsan_scoped_name(id, _dummy_p) \
|
|
|
|
__maybe_unused = kcsan_begin_scoped_access( \
|
|
|
|
&(var), sizeof(var), KCSAN_ACCESS_SCOPED | (type), \
|
|
|
|
&__kcsan_scoped_name(id, _))
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ASSERT_EXCLUSIVE_WRITER_SCOPED - assert no concurrent writes to @var in scope
|
|
|
|
*
|
|
|
|
* Scoped variant of ASSERT_EXCLUSIVE_WRITER().
|
|
|
|
*
|
|
|
|
* Assert that there are no concurrent writes to @var for the duration of the
|
|
|
|
* scope in which it is introduced. This provides a better way to fully cover
|
|
|
|
* the enclosing scope, compared to multiple ASSERT_EXCLUSIVE_WRITER(), and
|
|
|
|
* increases the likelihood for KCSAN to detect racing accesses.
|
|
|
|
*
|
|
|
|
* For example, it allows finding race-condition bugs that only occur due to
|
|
|
|
* state changes within the scope itself:
|
|
|
|
*
|
|
|
|
* .. code-block:: c
|
|
|
|
*
|
|
|
|
* void writer(void) {
|
|
|
|
* spin_lock(&update_foo_lock);
|
|
|
|
* {
|
|
|
|
* ASSERT_EXCLUSIVE_WRITER_SCOPED(shared_foo);
|
|
|
|
* WRITE_ONCE(shared_foo, 42);
|
|
|
|
* ...
|
|
|
|
* // shared_foo should still be 42 here!
|
|
|
|
* }
|
|
|
|
* spin_unlock(&update_foo_lock);
|
|
|
|
* }
|
|
|
|
* void buggy(void) {
|
|
|
|
* if (READ_ONCE(shared_foo) == 42)
|
|
|
|
* WRITE_ONCE(shared_foo, 1); // bug!
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* @var: variable to assert on
|
|
|
|
*/
|
|
|
|
#define ASSERT_EXCLUSIVE_WRITER_SCOPED(var) \
|
|
|
|
__ASSERT_EXCLUSIVE_SCOPED(var, KCSAN_ACCESS_ASSERT, __COUNTER__)
|
|
|
|
|
2020-02-06 23:46:25 +08:00
|
|
|
/**
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* ASSERT_EXCLUSIVE_ACCESS - assert no concurrent accesses to @var
|
2020-02-06 23:46:25 +08:00
|
|
|
*
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* Assert that there are no concurrent accesses to @var (no readers nor
|
|
|
|
* writers). This assertion can be used to specify properties of concurrent
|
|
|
|
* code, where violation cannot be detected as a normal data race.
|
2020-02-06 23:46:25 +08:00
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* For example, where exclusive access is expected after determining no other
|
|
|
|
* users of an object are left, but the object is not actually freed. We can
|
|
|
|
* check that this property actually holds as follows:
|
|
|
|
*
|
|
|
|
* .. code-block:: c
|
2020-02-06 23:46:25 +08:00
|
|
|
*
|
|
|
|
* if (refcount_dec_and_test(&obj->refcnt)) {
|
|
|
|
* ASSERT_EXCLUSIVE_ACCESS(*obj);
|
2020-03-05 22:21:09 +08:00
|
|
|
* do_some_cleanup(obj);
|
|
|
|
* release_for_reuse(obj);
|
2020-02-06 23:46:25 +08:00
|
|
|
* }
|
|
|
|
*
|
2020-06-23 15:09:04 +08:00
|
|
|
* Note:
|
2020-03-26 00:41:58 +08:00
|
|
|
*
|
2020-06-23 15:09:04 +08:00
|
|
|
* 1. ASSERT_EXCLUSIVE_ACCESS_SCOPED(), if applicable, performs more thorough
|
|
|
|
* checking if a clear scope where no concurrent accesses are expected exists.
|
|
|
|
*
|
|
|
|
* 2. For cases where the object is freed, `KASAN <kasan.html>`_ is a better
|
|
|
|
* fit to detect use-after-free bugs.
|
2020-03-05 22:21:09 +08:00
|
|
|
*
|
|
|
|
* @var: variable to assert on
|
2020-02-06 23:46:25 +08:00
|
|
|
*/
|
|
|
|
#define ASSERT_EXCLUSIVE_ACCESS(var) \
|
|
|
|
__kcsan_check_access(&(var), sizeof(var), KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ASSERT)
|
|
|
|
|
2020-03-26 00:41:58 +08:00
|
|
|
/**
|
|
|
|
* ASSERT_EXCLUSIVE_ACCESS_SCOPED - assert no concurrent accesses to @var in scope
|
|
|
|
*
|
|
|
|
* Scoped variant of ASSERT_EXCLUSIVE_ACCESS().
|
|
|
|
*
|
|
|
|
* Assert that there are no concurrent accesses to @var (no readers nor writers)
|
|
|
|
* for the entire duration of the scope in which it is introduced. This provides
|
|
|
|
* a better way to fully cover the enclosing scope, compared to multiple
|
|
|
|
* ASSERT_EXCLUSIVE_ACCESS(), and increases the likelihood for KCSAN to detect
|
|
|
|
* racing accesses.
|
|
|
|
*
|
|
|
|
* @var: variable to assert on
|
|
|
|
*/
|
|
|
|
#define ASSERT_EXCLUSIVE_ACCESS_SCOPED(var) \
|
|
|
|
__ASSERT_EXCLUSIVE_SCOPED(var, KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ASSERT, __COUNTER__)
|
|
|
|
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
/**
|
|
|
|
* ASSERT_EXCLUSIVE_BITS - assert no concurrent writes to subset of bits in @var
|
|
|
|
*
|
2020-03-26 00:41:58 +08:00
|
|
|
* Bit-granular variant of ASSERT_EXCLUSIVE_WRITER().
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
*
|
|
|
|
* Assert that there are no concurrent writes to a subset of bits in @var;
|
|
|
|
* concurrent readers are permitted. This assertion captures more detailed
|
|
|
|
* bit-level properties, compared to the other (word granularity) assertions.
|
|
|
|
* Only the bits set in @mask are checked for concurrent modifications, while
|
2020-03-05 22:21:09 +08:00
|
|
|
* ignoring the remaining bits, i.e. concurrent writes (or reads) to ~mask bits
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* are ignored.
|
|
|
|
*
|
|
|
|
* Use this for variables, where some bits must not be modified concurrently,
|
|
|
|
* yet other bits are expected to be modified concurrently.
|
|
|
|
*
|
|
|
|
* For example, variables where, after initialization, some bits are read-only,
|
|
|
|
* but other bits may still be modified concurrently. A reader may wish to
|
|
|
|
* assert that this is true as follows:
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* .. code-block:: c
|
|
|
|
*
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* ASSERT_EXCLUSIVE_BITS(flags, READ_ONLY_MASK);
|
|
|
|
* foo = (READ_ONCE(flags) & READ_ONLY_MASK) >> READ_ONLY_SHIFT;
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* Note: The access that immediately follows ASSERT_EXCLUSIVE_BITS() is assumed
|
|
|
|
* to access the masked bits only, and KCSAN optimistically assumes it is
|
|
|
|
* therefore safe, even in the presence of data races, and marking it with
|
|
|
|
* READ_ONCE() is optional from KCSAN's point-of-view. We caution, however, that
|
|
|
|
* it may still be advisable to do so, since we cannot reason about all compiler
|
|
|
|
* optimizations when it comes to bit manipulations (on the reader and writer
|
|
|
|
* side). If you are sure nothing can go wrong, we can write the above simply
|
|
|
|
* as:
|
|
|
|
*
|
|
|
|
* .. code-block:: c
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
*
|
|
|
|
* ASSERT_EXCLUSIVE_BITS(flags, READ_ONLY_MASK);
|
|
|
|
* foo = (flags & READ_ONLY_MASK) >> READ_ONLY_SHIFT;
|
|
|
|
*
|
|
|
|
* Another example, where this may be used, is when certain bits of @var may
|
|
|
|
* only be modified when holding the appropriate lock, but other bits may still
|
|
|
|
* be modified concurrently. Writers, where other bits may change concurrently,
|
|
|
|
* could use the assertion as follows:
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* .. code-block:: c
|
|
|
|
*
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* spin_lock(&foo_lock);
|
|
|
|
* ASSERT_EXCLUSIVE_BITS(flags, FOO_MASK);
|
2020-03-05 22:21:09 +08:00
|
|
|
* old_flags = flags;
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
* new_flags = (old_flags & ~FOO_MASK) | (new_foo << FOO_SHIFT);
|
|
|
|
* if (cmpxchg(&flags, old_flags, new_flags) != old_flags) { ... }
|
|
|
|
* spin_unlock(&foo_lock);
|
|
|
|
*
|
2020-03-05 22:21:09 +08:00
|
|
|
* @var: variable to assert on
|
|
|
|
* @mask: only check for modifications to bits set in @mask
|
kcsan: Introduce ASSERT_EXCLUSIVE_BITS(var, mask)
This introduces ASSERT_EXCLUSIVE_BITS(var, mask).
ASSERT_EXCLUSIVE_BITS(var, mask) will cause KCSAN to assume that the
following access is safe w.r.t. data races (however, please see the
docbook comment for disclaimer here).
For more context on why this was considered necessary, please see:
http://lkml.kernel.org/r/1580995070-25139-1-git-send-email-cai@lca.pw
In particular, before this patch, data races between reads (that use
@mask bits of an access that should not be modified concurrently) and
writes (that change ~@mask bits not used by the readers) would have been
annotated with "data_race()" (or "READ_ONCE()"). However, doing so would
then hide real problems: we would no longer be able to detect harmful
races between reads to @mask bits and writes to @mask bits.
Therefore, by using ASSERT_EXCLUSIVE_BITS(var, mask), we accomplish:
1. Avoid proliferation of specific macros at the call sites: by
including a single mask in the argument list, we can use the same
macro in a wide variety of call sites, regardless of how and which
bits in a field each call site actually accesses.
2. The existing code does not need to be modified (although READ_ONCE()
may still be advisable if we cannot prove that the data race is
always safe).
3. We catch bugs where the exclusive bits are modified concurrently.
4. We document properties of the current code.
Acked-by: John Hubbard <jhubbard@nvidia.com>
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>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Qian Cai <cai@lca.pw>
2020-02-12 00:04:23 +08:00
|
|
|
*/
|
|
|
|
#define ASSERT_EXCLUSIVE_BITS(var, mask) \
|
|
|
|
do { \
|
|
|
|
kcsan_set_access_mask(mask); \
|
|
|
|
__kcsan_check_access(&(var), sizeof(var), KCSAN_ACCESS_ASSERT);\
|
|
|
|
kcsan_set_access_mask(0); \
|
|
|
|
kcsan_atomic_next(1); \
|
|
|
|
} while (0)
|
|
|
|
|
2019-11-15 02:02:54 +08:00
|
|
|
#endif /* _LINUX_KCSAN_CHECKS_H */
|