From: sashiko-bot@kernel.org
To: "Thomas Richter" <tmricht@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH 1/2] s390/pai: Use PAI PMU index as parameter replacing event
Date: Fri, 07 Aug 2026 08:51:21 +0000 [thread overview]
Message-ID: <20260807085122.533281F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807083910.3771502-1-tmricht@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The PAI PMU lacks CPU hotplug state registration. When a per-task event is created, per-CPU data is allocated only for currently online CPUs. If a task migrates to a newly onlined CPU, PMU callbacks dereference a NULL per-CPU pointer, causing a kernel panic.
--
--- Patch [1]: [PATCH 1/2] s390/pai: Use PAI PMU index as parameter replacing event ---
commit a1e342cbbe1229dba8d0d235d003b35f9d061a5f
Author: Thomas Richter <tmricht@linux.ibm.com>
s390/pai: Use PAI PMU index as parameter replacing event
This patch updates the PAI PMU code to use the PAI index value directly
as a function argument instead of passing a pointer to struct perf_event.
This simplifies functions like pai_alloc_cpu() and pai_event_destroy_cpu()
without introducing any functional changes.
> diff --git a/arch/s390/kernel/perf_pai.c b/arch/s390/kernel/perf_pai.c
> index cdb8006220ca0..7c13f5586c793 100644
> --- a/arch/s390/kernel/perf_pai.c
> +++ b/arch/s390/kernel/perf_pai.c
[ ... ]
> @@ -318,6 +316,7 @@ static int pai_alloc_cpu(struct perf_event *event, int cpu)
>
> static int pai_alloc(struct perf_event *event)
> {
> + int idx = PAI_PMU_IDX(event);
> struct cpumask *maskptr;
> int cpu, rc = -ENOMEM;
>
> @@ -326,10 +325,10 @@ static int pai_alloc(struct perf_event *event)
> goto out;
>
> for_each_online_cpu(cpu) {
> - rc = pai_alloc_cpu(event, cpu);
> + rc = pai_alloc_cpu(idx, cpu);
[Severity: High]
This is a pre-existing issue, but does this allocation strategy handle CPU
hotplug correctly?
Since memory for the PMU context is only allocated for currently online
CPUs, what happens if a task migrates to a newly onlined CPU?
Looking at pai_add(), if a task is scheduled on a newly hotplugged CPU
where no memory was allocated, it seems mp->mapptr will be NULL:
arch/s390/kernel/perf_pai.c:pai_add() {
...
struct pai_map *cpump = mp->mapptr;
struct paiext_cb *pcb = cpump->paiext_cb;
...
}
Can this lead to a NULL pointer dereference when accessing cpump->paiext_cb?
Should the PAI PMU register for CPU hotplug states to ensure memory is
allocated when new CPUs come online?
> if (rc) {
> for_each_cpu(cpu, maskptr)
> - pai_event_destroy_cpu(event, cpu);
> + pai_event_destroy_cpu(idx, cpu);
> kfree(maskptr);
> goto out;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807083910.3771502-1-tmricht@linux.ibm.com?part=1
prev parent reply other threads:[~2026-08-07 8:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 8:39 [PATCH 1/2] s390/pai: Use PAI PMU index as parameter replacing event Thomas Richter
2026-08-07 8:39 ` [PATCH 2/2] s390/pai: Move locking to event init and delete Thomas Richter
2026-08-07 9:02 ` sashiko-bot
2026-08-07 8:51 ` 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=20260807085122.533281F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tmricht@linux.ibm.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.