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. Questions for discussion: 1. Is address-targeted watchpoint sampling a useful primitive for focused KCSAN debugging? 2. Should matching accesses bypass the normal `kcsan.skip_watch` interval, as proposed here, or should targeted mode retain its own sampling interval? 3. Is the existing KCSAN debugfs file an appropriate interface for configuring a single target? Hui Su (4): kcsan: add targeted watchpoint matching kcsan: add debugfs target control kcsan: add targeted watchpoint selftest docs: kcsan: document targeted watchpoint sampling Documentation/dev-tools/kcsan.rst | 17 ++++++++++++++ kernel/kcsan/core.c | 37 +++++++++++++++++++++++++++++++ kernel/kcsan/debugfs.c | 28 ++++++++++++++++++++++- kernel/kcsan/kcsan.h | 10 +++++++++ kernel/kcsan/selftest.c | 29 ++++++++++++++++++++++++ 5 files changed, 120 insertions(+), 1 deletion(-) base-commit: 4056b3c9d3c92ea45955641dbafeb9b960e146ef -- 2.55.0
