All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thomas Richter" <tmricht@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
	linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH 2/2] s390/pai: Move locking to event init and delete
Date: Fri, 07 Aug 2026 09:02:27 +0000	[thread overview]
Message-ID: <20260807090227.A46F21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807083910.3771502-2-tmricht@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing CPU hotplug support causes a NULL pointer dereference in `pai_add()` when a task with an active PAI event migrates to a newly onlined CPU.
--

--- Patch [2]: [PATCH 2/2] s390/pai: Move locking to event init and delete ---
commit fa13d9fdfca46f4567335a92efab0ab04b313967
Author: Thomas Richter <tmricht@linux.ibm.com>

s390/pai: Move locking to event init and delete

This commit moves the mutex locking from the per-CPU allocation functions
to the higher-level event allocation and deletion routines. No functional
changes are introduced.

> diff --git a/arch/s390/kernel/perf_pai.c b/arch/s390/kernel/perf_pai.c
> index 7c13f5586c793..03c5bda53cccb 100644
> --- a/arch/s390/kernel/perf_pai.c
> +++ b/arch/s390/kernel/perf_pai.c

[ ... ]

> @@ -390,10 +388,12 @@ static int pai_event_init(struct perf_event *event, int idx)
>  		}
>  	}
>  
> +	mutex_lock(&pai_reserve_mutex);
>  	if (event->cpu >= 0)
>  		rc = pai_alloc_cpu(idx, event->cpu);
>  	else
>  		rc = pai_alloc(event);

[Severity: High]
This is a pre-existing issue, but does the current design lack CPU hotplug
support?

Looking at pai_alloc() called here, it only allocates memory for currently
online CPUs:

pai_alloc() {
...
        for_each_online_cpu(cpu) {
                rc = pai_alloc_cpu(idx, cpu);
...

If a task-bound PAI event is created and a new CPU is hotplugged later, the
per-CPU mapptr for the new CPU appears to remain NULL.

When the task with the active event is scheduled onto the newly onlined
CPU, the perf core will call pai_add(), which seems to unconditionally
dereference cpump:

pai_add() {
        struct pai_map *cpump = mp->mapptr;
        struct paiext_cb *pcb = cpump->paiext_cb;

        if (++cpump->active_events == 1) {
...

Can this result in a kernel panic due to a NULL pointer dereference when
a task migrates to a newly onlined CPU?

> +	mutex_unlock(&pai_reserve_mutex);
>  	if (rc) {
>  		free_page(PAI_SAVE_AREA(event));
>  		goto out;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807083910.3771502-1-tmricht@linux.ibm.com?part=2

  reply	other threads:[~2026-08-07  9:02 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 [this message]
2026-08-07  8:51 ` [PATCH 1/2] s390/pai: Use PAI PMU index as parameter replacing event 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=20260807090227.A46F21F000E9@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.