From: sashiko-bot@kernel.org
To: "Sandipan Das" <sandipan.das@amd.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf/x86/amd/uncore: Add group validation
Date: Tue, 23 Jun 2026 11:04:44 +0000 [thread overview]
Message-ID: <20260623110444.C71BF1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <0f2cff983d79521e153d211ce412fedbc4ed942c.1782211518.git.sandipan.das@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Group validation incorrectly counts disabled or errored siblings.
--
commit a3401bf46a6300cee39613401a4f3512876a47f1
Author: Sandipan Das <sandipan.das@amd.com>
perf/x86/amd/uncore: Add group validation
This patch introduces group validation in the pmu->event_init() path for
the AMD uncore driver. It counts the hardware events targeting the PMU
in an event group and ensures they do not exceed the available hardware
counters, preventing failures later in pmu->add().
> diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
> index 9293ce50574da..15330cbab6a69 100644
> --- a/arch/x86/events/amd/uncore.c
> +++ b/arch/x86/events/amd/uncore.c
[ ... ]
> +static bool amd_uncore_group_valid(struct perf_event *event)
> +{
> + struct amd_uncore_pmu *pmu = event_to_amd_uncore_pmu(event);
> + struct perf_event *leader = event->group_leader;
> + struct perf_event *sibling;
> + int counters = 0;
> +
> + /* Ignore software events as they do not occupy hardware counters */
> + if (leader->pmu == event->pmu && !is_software_event(leader))
> + counters++;
> +
> + for_each_sibling_event(sibling, leader) {
> + if (sibling->pmu == event->pmu && !is_software_event(sibling))
> + counters++;
[Severity: Medium]
Is it possible that disabled or errored siblings are incorrectly counted here?
Users might create oversized groups and manually multiplex them by toggling
events on and off. If this loop unconditionally increments the hardware
counter usage for all siblings, could it reject valid requests from userspace?
Unlike the core x86 and Intel uncore PMU drivers, it appears this fails to
ignore events with state <= PERF_EVENT_STATE_OFF.
> + }
> +
> + /*
> + * When pmu->event_init() is called, the event is yet to be linked to
> + * its leader's sibling list, so it is counted separately
> + */
> + return (counters + 1) <= pmu->num_counters;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/0f2cff983d79521e153d211ce412fedbc4ed942c.1782211518.git.sandipan.das@amd.com?part=1
prev parent reply other threads:[~2026-06-23 11:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 10:49 [PATCH] perf/x86/amd/uncore: Add group validation Sandipan Das
2026-06-23 11:04 ` sashiko-bot [this message]
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=20260623110444.C71BF1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sandipan.das@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox