Re: [PATCH v11 16/19] perf env: Add mutex to protect lazy environment initialization

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Calling `mutex_destroy()` on an uninitialized mutex in `perf_env__exit()` causes undefined behavior, as stack-allocated `struct perf_env` instances in helper functions bypass `perf_env__init()`.
--

commit 08389321a4c748339a57c5404995d5a975c79c1e
Author: Ian Rogers <irogers@google.com>

    perf env: Add mutex to protect lazy environment initialization
    
    Introduce a mutex to 'struct perf_env' to safely protect lazy
    metadata setup, such as os_release or e_machine resolution,
    preventing concurrent initialization data races and memory leaks
    during multi-threaded profiling or symbol loading.

> diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
> index 28c54c58193e4..4de07cc7ef5da 100644
> --- a/tools/perf/util/env.c
> +++ b/tools/perf/util/env.c
> @@ -250,6 +250,8 @@ void perf_env__exit(struct perf_env *env)
>  {
>  	int i, j;
>  
> +	mutex_destroy(&env->lock);
> +

[Severity: Medium]
Could this trigger undefined behavior when perf_env__exit() is called on
stack-allocated environments that bypassed perf_env__init()?

For example, in x86__is_amd_cpu():

tools/perf/util/env.c:x86__is_amd_cpu() {
	struct perf_env env = { .total_mem = 0, };
	bool is_amd;

	perf_env__cpuid(&env);
	is_amd = perf_env__is_x86_amd_cpu(&env);
	perf_env__exit(&env);

	return is_amd;
}

The local env variable is zero-initialized but perf_env__init() is never
called, leaving env.lock uninitialized. Calling mutex_destroy() on an
uninitialized mutex triggers undefined behavior and may cause crashes under
sanitizers. 

This same pattern also exists in x86__is_intel_cpu().

>  	perf_env__purge_bpf(env);
>  	perf_env__purge_cgroups(env);
>  	zfree(&env->hostname);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602062452.2583619-1-irogers@google.com?part=16