Re: [PATCH] tracing: Make branch profiler counters atomic

[Steven Rostedt]

On Wed, 30 Sep 2026 11:07:28 +0800
nanshuaibo <nanshuaibo811@xxxxxxx> wrote:

> The branch profiler updates its static counters from arbitrary contexts. Concurrent updates can race and lose counts. KCSAN reports a data race between ftrace_likely_update() invocations.
> 
> Use relaxed compiler atomic operations for the counters. The profiler metadata is defined in compiler_types.h, before the kernel atomic API is available. The counters do not order accesses to other data.
> 
> Also use atomic loads when reading the counters for tracefs output and sorting, so readers do not race with atomic writers.
> 
> Tested on x86_64 QEMU/KVM with KCSAN and CONFIG_PROFILE_ANNOTATED_BRANCHES=y. The baseline reports the race in ftrace_likely_update(); it is not reported after this change.

FYI, Change log lines should be capped at 76 characters except for cut
and pasted output.

That said, NAK to the patch. The branch profile is a best effort and
known to be racy. It's to find where branches are most traveled, Their
exact numbers are not meaningful. No need for atomic operations.

-- Steve