On Mon, May 13, 2024 at 04:13:35PM +0200, Marco Elver wrote: > 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 Thank you for the background information! > 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. I do try my best. ;-) Thanx, Paul
