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

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

[Bramwel Barack]

In init_hw_perf_events(), a fallback block intentionally clears the
'err' variable to 0 when a vendor PMU driver is missing, allowing the
kernel to fall back to software events safely.

However, further down the initialization path, a second hardware safety
validation check is performed via check_hw_exists(). If this hardware check
fails, the execution control paths jump straight to the 'out_bad_pmu'
cleanup label. Because 'err' was cleared or initialized to 0 earlier, the
function erroneously returns 0 (Success) to the initialization manager,
despite wiping out the PMU configuration structures via memset.

Fix this by explicitly assigning -ENODEV to 'err' before jumping to the
cleanup sequence when check_hw_exists() fails.

Signed-off-by: Bramwel Barack  <bramwelbarack89@gmail.com>
---
 arch/x86/events/core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index d1af33d96d0a..81873eda5b17 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;
-
+	}
 	pr_cont("%s PMU driver.\n", x86_pmu.name);
 
 	/* enable userspace RDPMC usage by default */
-- 
2.55.0

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

[sashiko-bot]

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