> You should compare fast path disasm before/after, just to make codegen > isn't adversely affected.
I also checked the x86-64 fast-path code generation as suggested. In paired GCC and Clang comparisons, I found no new calls, stack spills, stack-frame adjustment, or callee-saved register saves on the disabled path. The detailed `__tsan_read8` disassembly comparison is in my reply to patch 1: https://lore.kernel.org/lkml/[email protected]/ > 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? Not exactly. This interface is not intended to prove that all accesses to a variable are race-free. The motivating use case is narrower: after a reproducer or report points to a suspicious address, make accesses overlapping that address eligible for watchpoint setup without unrelated accesses consuming the skip interval. I agree that function-scoped filtering and stress testing remain useful for looking for races around code changed in a fix. Targeted mode is complementary to that workflow when a known low-frequency location is difficult to reproduce. In the 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 `kcsan.skip_watch=4000` did not report those locations during its test window. This is evidence for that workload and window, not proof that the accesses are race-free when no report appears. > 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. Yes, bypassing the normal `kcsan.skip_watch` interval for matching accesses is the intended tradeoff in this RFC. Nonmatching accesses neither set up a watchpoint nor consume that interval. `target=off` restores normal sampling. Targeted mode is intended for focused debugging, not steady-state use. The hot-target cost is therefore expected. In the RFC measurements an enabled nonmatching target was 26.981 ns/access versus 24.549 ns/access upstream, while a deliberately hot matching target measured 81.1 us/access because every matching access entered `kcsan_setup_watchpoint()`. > 3. Is the existing KCSAN debugfs file an appropriate interface for configuring > a single target? > > This looks clean enough. Thanks. I'll keep the debugfs interface as proposed.
