From: Dapeng Mi <dapeng1.mi@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
Eranian Stephane <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Dapeng Mi <dapeng1.mi@intel.com>, Zide Chen <zide.chen@intel.com>,
Falcon Thomas <thomas.falcon@intel.com>,
Xudong Hao <xudong.hao@intel.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: [PATCH 6/8] perf/x86/intel: Validate return value of intel_pmu_init_hybrid()
Date: Fri, 5 Jun 2026 09:11:34 +0800 [thread overview]
Message-ID: <20260605011136.2043393-7-dapeng1.mi@linux.intel.com> (raw)
In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com>
The memory allocation for the x86_pmu.hybrid_pmu[] array in
intel_pmu_init_hybrid() can theoretically fail due to memory shortages.
If this occurs, the initialization of the x86 hybrid PMU would fail.
Currently, the code does not check the return value of the
intel_pmu_init_hybrid() function, which could lead to attempts to access
the uninitialized x86_pmu.hybrid_pmu[] array, potentially causing a
system panic.
So, adds a check for the return value of intel_pmu_init_hybrid() to
prevent invalid memory access in such scenarios. Besides, free the
created kmem cache when error occurs.
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
arch/x86/events/intel/core.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index ea3ab3050a3b..efd9caa3502c 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -7870,6 +7870,7 @@ __init int intel_pmu_init(void)
int version, i;
char *name;
struct x86_hybrid_pmu *pmu;
+ int ret;
/* Architectural Perfmon was introduced starting with Core "Yonah" */
if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
@@ -8539,7 +8540,9 @@ __init int intel_pmu_init(void)
*
* Initialize the common PerfMon capabilities here.
*/
- intel_pmu_init_hybrid(hybrid_big_small);
+ ret = intel_pmu_init_hybrid(hybrid_big_small);
+ if (ret < 0)
+ goto err;
x86_pmu.pebs_latency_data = grt_latency_data;
x86_pmu.get_event_constraints = adl_get_event_constraints;
@@ -8597,7 +8600,9 @@ __init int intel_pmu_init(void)
case INTEL_METEORLAKE:
case INTEL_METEORLAKE_L:
case INTEL_ARROWLAKE_U:
- intel_pmu_init_hybrid(hybrid_big_small);
+ ret = intel_pmu_init_hybrid(hybrid_big_small);
+ if (ret < 0)
+ goto err;
x86_pmu.pebs_latency_data = cmt_latency_data;
x86_pmu.get_event_constraints = mtl_get_event_constraints;
@@ -8628,7 +8633,9 @@ __init int intel_pmu_init(void)
pr_cont("Pantherlake Hybrid events, ");
name = "pantherlake_hybrid";
- intel_pmu_init_hybrid(hybrid_big_small);
+ ret = intel_pmu_init_hybrid(hybrid_big_small);
+ if (ret < 0)
+ goto err;
/* Initialize big core specific PerfMon capabilities.*/
pmu = &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX];
@@ -8643,7 +8650,9 @@ __init int intel_pmu_init(void)
pr_cont("Arrowlake Hybrid events, ");
name = "arrowlake_hybrid";
- intel_pmu_init_hybrid(hybrid_big_small);
+ ret = intel_pmu_init_hybrid(hybrid_big_small);
+ if (ret < 0)
+ goto err;
/* Initialize big core specific PerfMon capabilities.*/
pmu = &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX];
@@ -8660,7 +8669,9 @@ __init int intel_pmu_init(void)
pr_cont("Lunarlake Hybrid events, ");
name = "lunarlake_hybrid";
- intel_pmu_init_hybrid(hybrid_big_small);
+ ret = intel_pmu_init_hybrid(hybrid_big_small);
+ if (ret < 0)
+ goto err;
/* Initialize big core specific PerfMon capabilities.*/
pmu = &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX];
@@ -8685,7 +8696,9 @@ __init int intel_pmu_init(void)
break;
case INTEL_ARROWLAKE_H:
- intel_pmu_init_hybrid(hybrid_big_small_tiny);
+ ret = intel_pmu_init_hybrid(hybrid_big_small_tiny);
+ if (ret < 0)
+ goto err;
x86_pmu.pebs_latency_data = arl_h_latency_data;
x86_pmu.get_event_constraints = arl_h_get_event_constraints;
@@ -8720,7 +8733,9 @@ __init int intel_pmu_init(void)
case INTEL_NOVALAKE_L:
pr_cont("Novalake Hybrid events, ");
name = "novalake_hybrid";
- intel_pmu_init_hybrid(hybrid_big_small);
+ ret = intel_pmu_init_hybrid(hybrid_big_small);
+ if (ret < 0)
+ goto err;
x86_pmu.pebs_latency_data = nvl_latency_data;
x86_pmu.get_event_constraints = mtl_get_event_constraints;
@@ -8885,6 +8900,10 @@ __init int intel_pmu_init(void)
intel_aux_output_init();
return 0;
+
+err:
+ kmem_cache_destroy(x86_get_pmu(smp_processor_id())->task_ctx_cache);
+ return ret;
}
/*
--
2.34.1
next prev parent reply other threads:[~2026-06-05 1:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 1:11 [PATCH 0/8] perf/x86: Miscellaneous PMU bug fixes Dapeng Mi
2026-06-05 1:11 ` [PATCH 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Dapeng Mi
2026-06-05 1:11 ` [PATCH 2/8] perf/x86: Introduce is_x86_pmu() helper Dapeng Mi
2026-06-05 1:11 ` [PATCH 3/8] perf/x86: Update cap_user_rdpmc base on rdpmc user disable state Dapeng Mi
2026-06-05 1:11 ` [PATCH 4/8] perf/x86/intel: Fix redundant branch type check in intel_pmu_lbr_filter() Dapeng Mi
2026-06-05 1:11 ` [PATCH 5/8] perf/x86/intel: Fix kernel address leakages in LBR stack Dapeng Mi
2026-06-05 1:33 ` sashiko-bot
2026-06-05 3:20 ` Mi, Dapeng
2026-06-05 1:11 ` Dapeng Mi [this message]
2026-06-05 1:36 ` [PATCH 6/8] perf/x86/intel: Validate return value of intel_pmu_init_hybrid() sashiko-bot
2026-06-05 3:29 ` Mi, Dapeng
2026-06-05 1:11 ` [PATCH 7/8] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Dapeng Mi
2026-06-05 1:11 ` [PATCH 8/8] perf/core: Fix kernel register info leak via hardware skid Dapeng Mi
2026-06-05 1:38 ` sashiko-bot
2026-06-05 3:42 ` Mi, Dapeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260605011136.2043393-7-dapeng1.mi@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dapeng1.mi@intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=thomas.falcon@intel.com \
--cc=xudong.hao@intel.com \
--cc=zide.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox