On Wed, 30 Sep 2026 11:07:28 +0800 nanshuaibo <[email protected]> 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
