lkml.org 
[lkml]   [2021]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2021-07-06 10:45    [W:2.073 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site