Re: [PATCH v7 4/9] perf mutex: Add DO_ONCE() for one-time initialization

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf: data race and missing memory barriers in DO_ONCE()
--

commit 29753096ef417d4625af9a405f85df097ba45c30
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
perf mutex: Add DO_ONCE() for one-time initialization

This commit introduces a DO_ONCE() macro for lazy initialization across
multiple threads in perf user-space. It mirrors the kernel's DO_ONCE()
behavior using a statically initialized mutex and a boolean flag.

> diff --git a/tools/perf/util/mutex.h b/tools/perf/util/mutex.h
> index b85a80ad60386..87937970615ff 100644
> --- a/tools/perf/util/mutex.h
> +++ b/tools/perf/util/mutex.h
[ ... ]
> +/*
> + * Runs fn() exactly once however many threads race to it, the rest wait
> + * for it to finish; per call site state, so multiple sites wanting the
> + * same once use a common helper, as in the kernel's DO_ONCE().
> + */
> +#define DO_ONCE(fn, ...)						       \
> +	({								       \
> +		static bool ___done;					       \
> +		static DEFINE_MUTEX(___once_lock);			       \
> +		bool ___ret = false;					       \
> +									       \
> +		if (!___done) {						       \

[Severity: Medium]
Is an acquire memory barrier needed here? On weakly-ordered architectures,
a racing thread evaluating this lockless fast-path without an acquire
barrier (such as smp_load_acquire) could observe ___done as true while
reading stale data from fn()'s side effects. This plain read also
constitutes a data race that could trigger ThreadSanitizer warnings.

> +			mutex_lock(&___once_lock);			       \
> +			if (!___done) {					       \
> +				fn(__VA_ARGS__);			       \
> +				___done = true;				       \

[Severity: Medium]
Could the CPU or compiler reorder this plain store before the initialization
side effects of fn() are globally visible? A store-release barrier
(such as smp_store_release) might be necessary here so that threads on the
lockless fast-path do not access uninitialized data on architectures like
ARM64 or PowerPC.

> +				___ret = true;				       \
> +			}						       \
> +			mutex_unlock(&___once_lock);			       \
> +		}							       \
> +		___ret;							       \
> +	})

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001185400.2754753-1-acme@kernel.org?part=4