RFC: KCSAN single report "feature"

RFC: KCSAN single report "feature"

[Breno Leitao]

Hello Marco and KCSAN community

KCSAN rate-limits reports so that a given data race is printed at most once
per CONFIG_KCSAN_REPORT_ONCE_IN_MS (3s by default): duplicates within that
window are dropped, but once it elapses the race is printed again in full.

On a long-running machine a persistent race therefore reprints the same
multi-line report every few seconds for as long as the racy code runs, flooding
dmesg/netconsole with identical reports and drowning out genuinely new ones.

Raising REPORT_ONCE_IN_MS only widens the window — the full report still
eventually recurs — and setting it to 0 disables rate limiting entirely, so
there is no way today to get a race reported just once.

I have some debug kernel running in my of Meta fleet, with these debug features
and I would like to enable KCSAN, but, this behaviour is flooding our data
pipeline.

I've recently solved something similar on kmemleak and I am wondering if there
is interested in solving something similar on KCSAN.

	77d100d11c87e mm/kmemleak: dedupe verbose scan output by allocation backtrace

Would it be OK to have a "report once" mode that prints each race once and never
re-reports it,  maybe exposed as a bool CONFIG_KCSAN_REPORT_ONCE or a
kcsan.report_once module parameter ?

Thanks,
--breno

Re: RFC: KCSAN single report "feature"

[Marco Elver]

On Tue, 7 Jul 2026 at 16:34, Breno Leitao <leitao@debian.org> wrote:
>
> Hello Marco and KCSAN community
>
> KCSAN rate-limits reports so that a given data race is printed at most once
> per CONFIG_KCSAN_REPORT_ONCE_IN_MS (3s by default): duplicates within that
> window are dropped, but once it elapses the race is printed again in full.
>
> On a long-running machine a persistent race therefore reprints the same
> multi-line report every few seconds for as long as the racy code runs, flooding
> dmesg/netconsole with identical reports and drowning out genuinely new ones.
>
> Raising REPORT_ONCE_IN_MS only widens the window — the full report still
> eventually recurs — and setting it to 0 disables rate limiting entirely, so
> there is no way today to get a race reported just once.
>
> I have some debug kernel running in my of Meta fleet, with these debug features
> and I would like to enable KCSAN, but, this behaviour is flooding our data
> pipeline.
>
> I've recently solved something similar on kmemleak and I am wondering if there
> is interested in solving something similar on KCSAN.
>
>         77d100d11c87e mm/kmemleak: dedupe verbose scan output by allocation backtrace

kmemleak has the luxury of being able to allocate memory, and doesn't
have the context constraints that KCSAN does -- i.e. kmemleak doesn't
need to care about NMI context.

> Would it be OK to have a "report once" mode that prints each race once and never
> re-reports it,  maybe exposed as a bool CONFIG_KCSAN_REPORT_ONCE or a
> kcsan.report_once module parameter ?

A "report once" mode would necessitate a growable set. The problem is
that the KCSAN runtime must be compatible with all kernel contexts,
incl. NMI, and memory allocations are prohibited.

As such, we are limited to static pre-allocated buffers. That's why
CONFIG_KCSAN_REPORT_ONCE_IN_MS is the way it is today.

There are some comments here:
https://elixir.bootlin.com/linux/v7.2-rc1/source/kernel/kcsan/report.c#L95

We could increase REPORT_TIMES_MAX, or make it configurable, which
would let you set CONFIG_KCSAN_REPORT_ONCE_IN_MS to a very large value
and practically not get any reports, although the algorithm would need
improvement as it assumes the array of reports to skip is small.

An alternative solution which does not suffer the memory allocation
problem is to let userspace provide lists of functions we want to
ignore data races in; this is what the filter list is for:
https://docs.kernel.org/dev-tools/kcsan.html#debugfs-interface

The filterlist approach is the one taken by syzbot [1]: it collects
all the data race reports from various VMs, and then on VM restart
pre-populates the filter list so that previously seen data races are
not reported. The filter list takes function names, so adding function
'foo' will ignore all data races where 'foo' is at the top of the
stack trace. I expect that if you have at least several machines,
you'd benefit from ignoring data races even after a reboot. To me
that's a better design, and sidesteps the NMI allocation problem
entirely.

[1] https://github.com/google/syzkaller/commit/5681358a2a14647b64cdb97e0d19d3614986d31c

Thanks,
-- Marco