Messages in this thread | | | From | Marco Elver <> | Date | Tue, 6 Jul 2021 10:44:46 +0200 | Subject | Re: RCU vs data_race() |
| |
On Tue, 6 Jul 2021 at 10:00, Peter Zijlstra <peterz@infradead.org> wrote: [...] > In that case, would not an explicit: data_debug(addr) call (implemented > by KASAN/KCSAN/whoever), which would report whatever knowledge they have > about that address, be even more useful?
KCSAN/KASAN report data-races/memory errors as soon as they encounter them, but before they do, cannot give you any more than that (metadata if it exists, but not sure it can be interpreted in any useful way before an error occurs).
But maybe I misunderstood. Is data_debug() meant to not return anything and instead just be a "fake access"?
For those, we already have various existing primitives:
-- KCSAN: ASSERT_EXCLUSIVE_{ACCESS,WRITER}() (https://www.kernel.org/doc/html/latest/dev-tools/kcsan.html#race-detection-beyond-data-races)
-- All sanitizers (KASAN & KCSAN right now): <linux/instrumented.h>: instrument_*() calls, for generic explicit instrumentation.
-- For sanitizer-specific checks, there's everything else in <linux/{kasan,kcsan}-checks.h>, but instrumented.h should be preferred.
Thanks, -- Marco
| |