On Fri, 10 May 2024 at 16:11, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: [...] > > > Does this mean that KCSAN/etc treats the files in kernel/rcu/ > > > differently than the "Rest of Kernel"? Or what? > > > > > > And how is it enforced? > > > > I can only find the strnstr(buf, "rcu") checks in skip_report(), > > but they only cover the KCSAN_REPORT_VALUE_CHANGE_ONLY case... > > Huh, new one on me! When I run KCSAN, I set CONFIG_KCSAN_STRICT=y, > which implies CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n, which should > prevent skip_report() from even being invoked. The strnstr hack goes back to the first version of KCSAN released in v5.8 [1]. It was added in response to Paul wanting the "stricter" treatment for RCU even while KCSAN was still in development, and back then syzbot was the first test system using KCSAN. Shortly after Paul added a KCSAN config for rcutorture with a laundry list of options to make KCSAN "strict" (before we eventually added CONFIG_KCSAN_STRICT which greatly simplified that). While the strnstr(.., "rcu") rules are redundant when using the stricter rules (at least CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n is set), we're keeping the "rcu" special case around because there are test robots and fuzzers that use the default KCSAN config (unlike rcutorture). And because we know that RCU likes the stricter rules, the "value change only" filter is ignored in all KCSAN configs for rcu-related functions. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/kcsan/report.c?id=v5.8 Back then syzbot occasionally reported RCU data races, but these days rcutorture probably finds all of them before syzbot ever gets its hands on new code. Thanks, -- Marco
