All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dapeng Mi" <dapeng1.mi@linux.intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v3 3/8] perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts
Date: Fri, 17 Jul 2026 09:31:11 +0000	[thread overview]
Message-ID: <20260717093111.A5A0F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260717080342.1879573-4-dapeng1.mi@linux.intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Setting `cpuc->pmu = NULL` on initialization failure triggers a user-triggerable `WARN_ON_ONCE` in `x86_get_pmu()`.

Pre-existing issues:
- [High] Unchecked MSR writes in NMI handler cause a #GP fault on asymmetric PMU configurations.
--

--- Patch [3]: [Patch v3 3/8] perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts ---
commit 2ef12c59a0f0eb0a83a45dd11cf187ca55beecdf
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts
    
Fix invalid container conversions in failure paths by clearing cpuc->pmu to
NULL when check_hw_exists() fails, and validating cpuc->pmu in
intel_pmu_cpu_dead(). A new helper x86_get_static_pmu() is added.

> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index b39c6ce0efb5c..a991fc4f1575f 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -6329,8 +6329,10 @@ static bool init_hybrid_pmu(int cpu)
>  
>  	intel_pmu_check_hybrid_pmus(pmu);
>  
> -	if (!check_hw_exists(&pmu->pmu, pmu->cntr_mask, pmu->fixed_cntr_mask))
> +	if (!check_hw_exists(&pmu->pmu, pmu->cntr_mask, pmu->fixed_cntr_mask)) {
> +		cpuc->pmu = NULL;

[Severity: High]
Does setting cpuc->pmu to NULL here trigger a warning in x86_get_pmu()?

If check_hw_exists() fails (e.g., due to a hypervisor restricting PMU MSRs),
we now set cpuc->pmu to NULL but leave the CPU in the possible_cpus mask.

If a user later opens a perf event utilizing Architectural LBRs (like perf
record -b), x86_reserve_hardware() calls reserve_lbr_buffers() which
iterates over all possible CPUs:

arch/x86/events/intel/lbr.c:reserve_lbr_buffers() {
	...
	for_each_possible_cpu(cpu) {
		kmem_cache = x86_get_pmu(cpu)->task_ctx_cache;
	...
}

Because the failed CPU's cpuc->pmu is NULL, x86_get_pmu() hits its strict
WARN_ON_ONCE(!cpuc->pmu) assertion. If panic_on_warn=1 is set, could this
upgrade a graceful PMU initialization failure into a local panic?

Since intel_pmu_cpu_dead() now safely guards against the invalid cast with
cpuc->pmu != pmu, is this assignment necessary?

[Severity: High]
This is a pre-existing issue, but does failing check_hw_exists() leave the
CPU vulnerable to a #GP fault during a spurious NMI?

If a CPU is brought online but its PMU MSRs are disabled by a hypervisor,
initialization for that CPU aborts here. However, perf_event_nmi_handler()
is registered globally if at least one CPU succeeds.

If an active perf event runs on a healthy CPU (so active_events > 0), and a
spurious or broadcast NMI strikes the broken CPU, it will execute:

intel_pmu_handle_irq()
    __intel_pmu_disable_all(true)
        wrmsrq(MSR_CORE_PERF_GLOBAL_CTRL, 0);

Could accessing this non-existent MSR on the failed CPU trigger an unchecked
#GP fault and kernel panic?

>  		return false;
> +	}
>  
>  	pr_info("%s PMU driver: ", pmu->name);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717080342.1879573-1-dapeng1.mi@linux.intel.com?part=3

  reply	other threads:[~2026-07-17  9:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  8:03 [Patch v3 0/8] perf/x86: Miscellaneous PMU bug fixes and optimizations Dapeng Mi
2026-07-17  8:03 ` [Patch v3 1/8] perf/x86: Unregister PMI handler on PMU init failure Dapeng Mi
2026-07-17  8:33   ` sashiko-bot
2026-07-17  8:03 ` [Patch v3 2/8] perf/x86: Free hybrid state " Dapeng Mi
2026-07-17  8:03 ` [Patch v3 3/8] perf/x86: Guard intel_pmu_cpu_dead() against invalid hybrid PMU casts Dapeng Mi
2026-07-17  9:31   ` sashiko-bot [this message]
2026-07-17  8:03 ` [Patch v3 4/8] perf/x86/intel: Unwind cpuc state if PEBS buffer setup fails Dapeng Mi
2026-07-17  8:03 ` [Patch v3 5/8] perf/x86: Remove stale fixed counter helper and fix hybrid PMU access Dapeng Mi
2026-07-17  8:03 ` [Patch v3 6/8] perf/x86/intel: Fix intel_cap handling on hybrid PMUs Dapeng Mi
2026-07-17  8:03 ` [Patch v3 7/8] perf/x86: Optimize ACR handling in match_prev_assignment() Dapeng Mi
2026-07-17  8:03 ` [Patch v3 8/8] perf/x86/intel: Prevent drain_pebs() reentry Dapeng Mi
2026-07-17 10:38   ` sashiko-bot

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=20260717093111.A5A0F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.