Many patterns that involve data-racy accesses often deliberately ignore normal synchronization rules to avoid taking a lock.
If we have a lock-guarded variable on which we do a lock-less data-racy access, rather than having to write context_unsafe(data_race(..)), simply make the data_race(..) macro imply context-unsafety. The data_race() macro already denotes the intent that something subtly unsafe is about to happen, so it should be clear enough as-is. Signed-off-by: Marco Elver <[email protected]> --- v4: * Rename capability -> context analysis. v2: * New patch. --- include/linux/compiler.h | 2 ++ lib/test_context-analysis.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 04487c9bd751..110b28dfd1d1 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -190,7 +190,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, #define data_race(expr) \ ({ \ __kcsan_disable_current(); \ + disable_context_analysis(); \ auto __v = (expr); \ + enable_context_analysis(); \ __kcsan_enable_current(); \ __v; \ }) diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c index 2dc404456497..1c5a381461fc 100644 --- a/lib/test_context-analysis.c +++ b/lib/test_context-analysis.c @@ -92,6 +92,8 @@ static void __used test_raw_spinlock_trylock_extra(struct test_raw_spinlock_data { unsigned long flags; + data_race(d->counter++); /* no warning */ + if (raw_spin_trylock_irq(&d->lock)) { d->counter++; raw_spin_unlock_irq(&d->lock); -- 2.52.0.322.g1dd061c0dc-goog
