On Wed, 14 Oct 2026 at 11:52, Hui Su <[email protected]> wrote: > > Hi, > > While investigating a low-frequency scheduler access around `calc_load_idx` in > `kernel/sched/loadavg.c`, I found that KCSAN's per-CPU `kcsan.skip_watch` > interval can make focused reproduction difficult. Unrelated instrumented > accesses on the same CPUs may consume the interval before execution reaches a > known suspicious address. This is a limitation in focused-debugging control; > the proposal leaves the default sampling policy unchanged. > > Setting `kcsan.skip_watch=0` removes the interval globally and can make > watchpoint setup much more frequent for all eligible accesses. The existing > debugfs whitelist and blacklist filter which reports are emitted after > watchpoint selection; they do not select which addresses may set up a > watchpoint. There is currently no runtime control to focus setup attempts on > one known address while leaving unrelated accesses out of that selection. > > This RFC adds an optional single-address target to the KCSAN debugfs > interface. When enabled, a non-atomic access is eligible to set up a > watchpoint > only when its byte range contains the target address. Matching accesses bypass > the normal `kcsan.skip_watch` interval; nonmatching accesses neither set up a > watchpoint nor consume that interval. The target can be specified as an > address > or a kallsyms symbol, including `module:symbol`; `target=off` restores normal > sampling. A static key guards the disabled path. > > Patch 1 adds single-address target matching and the static-key-guarded runtime > state. Patch 2 exposes address and symbol targets through debugfs, patch 3 > tests the matching semantics, and patch 4 documents the interface and its > performance implications. The standalone integration module used for runtime > checks is local and is not included in the series. > > Testing: > - x86_64 GCC and Clang `bzImage modules` builds completed, and the candidate's > built-in KCSAN selftest passed 4/4. Runtime validation recorded setup > activity for exact-address and `module:symbol` targets, none for a > nonmatching target, and normal sampling after `target=off`. > - In a separate motivating loadavg run, targeting `calc_load_idx` produced a > KCSAN report involving `calc_global_load()` and `calc_load_nohz_start()`. A > separate upstream run with the default `skip_watch=4000` did not report > those locations during its test window. > - Across 10 rounds of 1,000,000 accesses, medians were `24.549 ns/access` > upstream, `24.654 ns/access` with targeting disabled, and `26.981 ns/access` > with an enabled nonmatching target. The disabled-path results were > indistinguishable at this measurement granularity. A separate 10-round, > 10,000-access hot-match run measured `81.1 us/access`: every matching > access enters `kcsan_setup_watchpoint()`, so this includes setup slow-path > work and represents focused debugging rather than normal use.
You should compare fast path disasm before/after, just to make codegen isn't adversely affected. > Questions for discussion: > 1. Is address-targeted watchpoint sampling a useful primitive for focused > KCSAN debugging? On surface, it seems helpful. But there's another angle: The need for reproduction arises because we want to debug an issue, and the fix it with a code change; after the code change and a recompile, are there new data races that were introduced as a side-effect? Perhaps the original data race you were hunting is gone, but new ones may have been introduced. So my approach has never been to try and focus on a single data race, but look for data races that may have appeared adjacent to code I touched (filtering based on function name). The method of reproduction are stress tests that more or less reliably trigger the original data race, but should also trigger data races (if they exist) adjacent to the code being scrutinized. But perhaps what you're after is asking "are all accesses to this variable data race free" only? > 2. Should matching accesses bypass the normal `kcsan.skip_watch` interval, as > proposed here, or should targeted mode retain its own sampling interval? It might become quite slow for frequently accessed data, but perhaps that's intentional if we want maximum races detected for focused testing. > 3. Is the existing KCSAN debugfs file an appropriate interface for configuring > a single target? This looks clean enough.
