All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zide Chen" <zide.chen@intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V3 7/8] perf/x86/intel/uncore: Fix uncore_box ref/unref ordering
Date: Thu, 11 Jun 2026 16:29:52 +0000	[thread overview]
Message-ID: <20260611162952.AD18A1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260611160033.66760-8-zide.chen@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Tearing down the uncore box (unmapping MMIO) before the perf core stops active events causes a use-after-unmap during CPU offline, leading to a kernel panic.
--

commit e2e044b2e3ac13715fc0c671d7186d9b5f0626a5
Author: Zide Chen <zide.chen@intel.com>

perf/x86/intel/uncore: Fix uncore_box ref/unref ordering

This commit swaps the call order in the CPU online and offline paths
so that uncore_box_{ref,unref}() runs at the point where the box CPU
reflects the correct context.

> diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
> index feb8c3b0076b2..b9ac2f7d31caa 100644
> --- a/arch/x86/events/intel/uncore.c
> +++ b/arch/x86/events/intel/uncore.c
> @@ -1580,9 +1580,15 @@ static int uncore_event_cpu_offline(unsigned int cpu)
>  {
>  	int die, target;
>  
> +	/* Clear the references */
> +	die = topology_logical_die_id(cpu);
> +	uncore_box_unref(uncore_msr_uncores, die);
> +	uncore_box_unref(uncore_mmio_uncores, die);

[Severity: High]
Will this early unref cause a use-after-unmap panic during CPU offline?

During CPU offline, the CPUHP_AP_PERF_X86_UNCORE_ONLINE teardown callback
runs before the CPUHP_AP_PERF_ONLINE callback.

When the last CPU on a die goes offline, this uncore_box_unref() drops refcnt
to 0 and calls uncore_box_exit(). For MMIO PMUs, this leads to
iounmap(box->io_addr) without clearing the box->io_addr pointer.

Later in the offline process, the CPUHP_AP_PERF_ONLINE callback runs
perf_event_exit_cpu_context(), which stops active events via:

uncore_pmu_event_stop() -> uncore_perf_event_update() -> uncore_mmio_read_counter()

Since uncore_mmio_read_counter() does this:

arch/x86/events/intel/uncore.c:uncore_mmio_read_counter() {
    ...
    return readq(box->io_addr + event->hw.event_base);
}

Will it proceed to read from the unmapped box->io_addr because the active
events have not been stopped yet?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611160033.66760-1-zide.chen@intel.com?part=7

  reply	other threads:[~2026-06-11 16:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 16:00 [PATCH v3 0/8] perf/x86/intel/uncore: PMU setup robustness fixes Zide Chen
2026-06-11 16:00 ` [PATCH V3 1/8] perf/x86/intel/uncore: Fix PCI PMU cleanup on setup failure Zide Chen
2026-06-11 16:26   ` sashiko-bot
2026-06-11 16:00 ` [PATCH V3 2/8] perf/x86/intel/uncore: Fix refcnt and other cleanups Zide Chen
2026-06-11 16:29   ` sashiko-bot
2026-06-12  0:52   ` Mi, Dapeng
2026-06-11 16:00 ` [PATCH V3 3/8] perf/x86/intel/uncore: Let init_box() callback report failures Zide Chen
2026-06-11 16:38   ` sashiko-bot
2026-06-11 16:00 ` [PATCH V3 4/8] perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails Zide Chen
2026-06-11 16:00 ` [PATCH V3 5/8] perf/x86/intel/uncore: Factor out box setup code Zide Chen
2026-06-11 16:00 ` [PATCH V3 6/8] perf/x86/intel/uncore: Introduce PMU flags and broken state Zide Chen
2026-06-11 16:30   ` sashiko-bot
2026-06-12  0:53   ` Mi, Dapeng
2026-06-11 16:00 ` [PATCH V3 7/8] perf/x86/intel/uncore: Fix uncore_box ref/unref ordering Zide Chen
2026-06-11 16:29   ` sashiko-bot [this message]
2026-06-12  0:55   ` Mi, Dapeng
2026-06-11 16:00 ` [PATCH V3 8/8] perf/x86/intel/uncore: Implement lazy setup for MSR/MMIO PMUs Zide Chen
2026-06-11 16:33   ` 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=20260611162952.AD18A1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --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 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.