From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Zide Chen <zide.chen@intel.com>,
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,
Xudong Hao <xudong.hao@intel.com>,
Falcon Thomas <thomas.falcon@intel.com>,
Steve Wahl <steve.wahl@hpe.com>
Subject: Re: [PATCH 1/2] perf/x86/intel/uncore: Skip discovery table for offline dies
Date: Thu, 30 Oct 2025 09:37:55 +0800 [thread overview]
Message-ID: <8b53854e-f407-4c58-badc-01327d2d4be0@linux.intel.com> (raw)
In-Reply-To: <20251029220711.57909-1-zide.chen@intel.com>
On 10/30/2025 6:07 AM, Zide Chen wrote:
> This warning can be triggered if NUMA is disabled and the system
> boots with fewer CPUs than the number of CPUs in die 0.
>
> WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]
>
> Currently, the discovery table continues to be parsed even if all CPUs
> in the associated die are offline. This can lead to an array overflow
> at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may
> trigger the warning above or cause other issues.
>
> Reported-by: Steve Wahl <steve.wahl@hpe.com>
> Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables")
> Signed-off-by: Zide Chen <zide.chen@intel.com>
> ---
> arch/x86/events/intel/uncore.c | 4 ++++
> arch/x86/events/intel/uncore_discovery.c | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
> index ee586eb714ec..5c3aeea5c78d 100644
> --- a/arch/x86/events/intel/uncore.c
> +++ b/arch/x86/events/intel/uncore.c
> @@ -1380,6 +1380,10 @@ static void uncore_pci_pmus_register(void)
>
> for (node = rb_first(type->boxes); node; node = rb_next(node)) {
> unit = rb_entry(node, struct intel_uncore_discovery_unit, node);
> +
> + if (WARN_ON(unit->die >= uncore_max_dies()))
Base on my understanding, it seems an valid situation which could happen.
If so, we'd better remove the WARN_on to avoid it mislead users. Thanks.
> + continue;
> +
> pdev = pci_get_domain_bus_and_slot(UNCORE_DISCOVERY_PCI_DOMAIN(unit->addr),
> UNCORE_DISCOVERY_PCI_BUS(unit->addr),
> UNCORE_DISCOVERY_PCI_DEVFN(unit->addr));
> diff --git a/arch/x86/events/intel/uncore_discovery.c b/arch/x86/events/intel/uncore_discovery.c
> index 1bf6e4288577..d6aee12139f1 100644
> --- a/arch/x86/events/intel/uncore_discovery.c
> +++ b/arch/x86/events/intel/uncore_discovery.c
> @@ -388,7 +388,7 @@ static bool intel_uncore_has_discovery_tables_pci(int *ignore)
> (val & UNCORE_DISCOVERY_DVSEC2_BIR_MASK) * UNCORE_DISCOVERY_BIR_STEP;
>
> die = get_device_die_id(dev);
> - if (die < 0)
> + if ((die < 0) || (die >= uncore_max_dies()))
> continue;
>
> parse_discovery_table(dev, die, bar_offset, &parsed, ignore);
next prev parent reply other threads:[~2025-10-30 1:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 22:07 [PATCH 1/2] perf/x86/intel/uncore: Skip discovery table for offline dies Zide Chen
2025-10-29 22:07 ` [PATCH 2/2] perf/x86/intel/uncore: Fix die ID init and look up bugs Zide Chen
2025-10-30 1:39 ` Mi, Dapeng
2025-10-30 5:17 ` Chen, Zide
2025-11-13 22:33 ` Steve Wahl
2025-10-30 1:37 ` Mi, Dapeng [this message]
2025-10-30 4:38 ` [PATCH 1/2] perf/x86/intel/uncore: Skip discovery table for offline dies Chen, Zide
2025-10-30 6:23 ` Mi, Dapeng
2025-11-13 22:32 ` Steve Wahl
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=8b53854e-f407-4c58-badc-01327d2d4be0@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=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=steve.wahl@hpe.com \
--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 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.