Re: [PATCH] perf/x86: Fix missing error code in init_hw_perf_events()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf/x86: inconsistent initcall return semantics on PMU fallback
--

commit ddd975294722d296c4cdeacb54faa85cadfe14fb
Author: Bramwel Barack <bramwelbarack89@gmail.com>

perf/x86: Fix missing error code in init_hw_perf_events()

This commit assigns -ENODEV to err when check_hw_exists() fails in
init_hw_perf_events(). The commit message states this fixes a missing error
code, preventing the function from returning 0 when hardware checks fail and
the code jumps to the out_bad_pmu cleanup path.

> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index d1af33d96d0a3..81873eda5b17b 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2164,9 +2164,10 @@ static int __init init_hw_perf_events(void)
>  	pmu_check_apic();
>  
>  	/* sanity check that the hardware exists or is emulated */
> -	if (!check_hw_exists(&pmu, x86_pmu.cntr_mask, x86_pmu.fixed_cntr_mask))
> +	if (!check_hw_exists(&pmu, x86_pmu.cntr_mask, x86_pmu.fixed_cntr_mask)) {
> +		err = -ENODEV;
>  		goto out_bad_pmu;
> -
> +	}

[Severity: Medium]
Does this change introduce inconsistent return semantics for the PMU fallback
path?

The x86 perf core uses the out_bad_pmu cleanup path to gracefully fall back
to software events when hardware is unsupported or broken. Earlier in
init_hw_perf_events(), when no vendor PMU driver is present, the code
explicitly forces err = 0 to signal a successful fallback rather than a fatal
initialization failure:

	if (err != 0) {
		pr_cont("no PMU driver, software events only.\n");
		err = 0;
		goto out_bad_pmu;
	}

If check_hw_exists() validation fails, it similarly falls back to software
events. Prior to this patch, it correctly inherited err = 0. Setting
err = -ENODEV introduces an inconsistent state where functionally identical
fallback paths return different codes (0 vs -ENODEV).

Can this cause initcall_debug and tracepoints (trace_initcall_finish) to
erroneously record a kernel initialization failure despite a successful
software PMU fallback?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920065510.15362-1-bramwelbarack89@gmail.com?part=1