From: sashiko-bot@kernel.org
To: "Zide Chen" <zide.chen@intel.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 2/7] perf/x86/intel/uncore: Let init_box() callback report failures
Date: Thu, 14 May 2026 02:14:24 +0000 [thread overview]
Message-ID: <20260514021424.821EEC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260512233048.9577-3-zide.chen@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The adl_uncore_msr_init_box callback was missed during the return type conversion and still returns void, causing a build failure and a runtime functional regression.
--
commit 9d842c01126a1db0940fbdd8cefa558fa67a3758
Author: Zide Chen <zide.chen@intel.com>
perf/x86/intel/uncore: Let init_box() callback report failures
The init_box() callback currently returns void, so initialization
failures are silently ignored and the box is still marked initialized.
Change the callback to return int so platform code can report errors
back to the common uncore layer.
> diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
> index 2e41a66f00551..25a44d3de6e7d 100644
> --- a/arch/x86/events/intel/uncore.h
> +++ b/arch/x86/events/intel/uncore.h
> @@ -129,7 +129,7 @@ struct intel_uncore_type {
> #define events_group attr_groups[2]
>
> struct intel_uncore_ops {
> - void (*init_box)(struct intel_uncore_box *);
> + int (*init_box)(struct intel_uncore_box *);
It appears the return type for the init_box callback was changed here, but
adl_uncore_msr_init_box() in arch/x86/events/intel/uncore_snb.c was missed
and still returns void:
static void adl_uncore_msr_init_box(struct intel_uncore_box *box)
{
if (box->pmu->pmu_idx == 0)
wrmsrq(ADL_UNC_PERF_GLOBAL_CTL, SNB_UNC_GLOBAL_CTL_EN);
}
Could this cause a build warning or failure (e.g., incompatible pointer
type)?
Also, at runtime, uncore_box_init() expects an int return value. Would it
end up reading an uninitialized return value from the eax register?
If the last operation in adl_uncore_msr_init_box() is wrmsrq(), which
loads SNB_UNC_GLOBAL_CTL_EN into eax, could this residual non-zero value
cause uncore_box_init() to incorrectly treat the initialization as a failure?
If the initialization failure marks the PMU as broken, would this render the
Alder Lake (ADL) MSR uncore PMU inaccessible to userspace?
> void (*exit_box)(struct intel_uncore_box *);
> void (*disable_box)(struct intel_uncore_box *);
> void (*enable_box)(struct intel_uncore_box *);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512233048.9577-1-zide.chen@intel.com?part=2
next prev parent reply other threads:[~2026-05-14 2:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 23:30 [PATCH 0/7] perf/x86/intel/uncore: PMU setup robustness fixes Zide Chen
2026-05-12 23:30 ` [PATCH 1/7] perf/x86/intel/uncore: Rename refcount fields and other cleanups Zide Chen
2026-05-13 0:26 ` Ian Rogers
2026-05-14 0:58 ` sashiko-bot
2026-05-12 23:30 ` [PATCH 2/7] perf/x86/intel/uncore: Let init_box() callback report failures Zide Chen
2026-05-13 0:23 ` Ian Rogers
2026-05-14 2:14 ` sashiko-bot [this message]
2026-05-12 23:30 ` [PATCH 3/7] perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails Zide Chen
2026-05-13 0:30 ` Ian Rogers
2026-05-12 23:30 ` [PATCH 4/7] perf/x86/intel/uncore: Factor out box setup code Zide Chen
2026-05-13 0:27 ` Ian Rogers
2026-05-14 3:34 ` sashiko-bot
2026-05-12 23:30 ` [PATCH 5/7] perf/x86/intel/uncore: Introduce PMU flags and broken state Zide Chen
2026-05-13 0:28 ` Ian Rogers
2026-05-14 4:27 ` sashiko-bot
2026-05-12 23:30 ` [PATCH 6/7] perf/x86/intel/uncore: Fix uncore_box ref/unref ordering on CPU hotplug Zide Chen
2026-05-13 0:32 ` Ian Rogers
2026-05-13 8:59 ` Mi, Dapeng
2026-05-13 18:43 ` Chen, Zide
2026-05-14 5:12 ` sashiko-bot
2026-05-12 23:30 ` [PATCH 7/7] perf/x86/intel/uncore: Implement lazy setup for MSR/MMIO PMU Zide Chen
2026-05-13 0:34 ` Ian Rogers
2026-05-13 9:03 ` Mi, Dapeng
2026-05-13 16:47 ` Chen, Zide
2026-05-14 5: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=20260514021424.821EEC19425@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox