[RFC PATCH 0/4] kcsan: add targeted watchpoint sampling

[Hui Su]

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