From: sashiko-bot@kernel.org
To: "Thomas Richter" <tmricht@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH] s390/cpum_cf: Handle CPU hotplug add and delete 6
Date: Mon, 03 Aug 2026 16:43:18 +0000 [thread overview]
Message-ID: <20260803164318.E73BC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260803161651.3803702-1-tmricht@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The CPU hotplug online handler allocates `cpuhw` with a hardcoded reference count of 1, ignoring the actual number of active users tracked by `tskcnt`. When any single active per-task event closes, it drops the newly onlined CPU's reference count to 0, prematurely freeing the infrastructure.
- [High] Unconditional freeing of CPU-bound event infrastructure during CPU hotplug offline permanently breaks those events upon subsequent online.
--
--- Patch [1]: [PATCH] s390/cpum_cf: Handle CPU hotplug add and delete 6 ---
commit 8c8ba5511cad2b2a0060e9a629b6a2e2df504f2d
Author: Thomas Richter <tmricht@linux.ibm.com>
s390/cpum_cf: Handle CPU hotplug add and delete 6
This commit changes the CPUMF PMU initialization to track the number of
active task-context events and allocate per-CPU infrastructure during CPU
hotplug add when these events are present. This prevents a NULL pointer
dereference panic when a per-task process is scheduled on a newly onlined
CPU that wasn't present during the initial perf event creation.
> diff --git a/arch/s390/kernel/perf_cpum_cf.c b/arch/s390/kernel/perf_cpum_cf.c
> index 2076ac22e2c49..c94334a4cfc4b 100644
> --- a/arch/s390/kernel/perf_cpum_cf.c
> +++ b/arch/s390/kernel/perf_cpum_cf.c
[ ... ]
> @@ -1105,13 +1136,13 @@ static int cpum_cf_online_cpu(unsigned int cpu)
> {
> int rc = 0;
>
> - /*
> - * Ignore notification for perf_event_open().
> - * Handle only /dev/hwctr device sessions.
> - */
> mutex_lock(&cfset_ctrset_mutex);
> - if (refcount_read(&cfset_opencnt)) {
> + /* Allocate per-CPU infrastructure when per-task context active. */
> + mutex_lock(&pmc_reserve_mutex);
> + if (atomic_read(&cpu_cf_root.tskcnt))
> rc = cpum_cf_alloc_cpu(cpu);
[Severity: High]
Does this code assign a reference count of 1 to the newly allocated
infrastructure regardless of how many active users are tracked by tskcnt?
If tskcnt is greater than 1, and a single task event closes,
cpum_cf_free() will decrement the reference count on all online CPUs.
Would this drop the reference count on this newly onlined CPU to 0, prematurely
freeing the infrastructure while other events or /dev/hwctr sessions are
still active?
> + mutex_unlock(&pmc_reserve_mutex);
> + if (refcount_read(&cfset_opencnt)) {
> if (!rc)
> cfset_online_cpu(cpu);
> }
> @@ -1130,13 +1161,12 @@ static int cpum_cf_offline_cpu(unsigned int cpu)
> * perf_event_open() created events. Perf common code triggers event
> * destruction when the event file descriptor is closed.
> *
> - * Handle only /dev/hwctr device sessions.
> + * Handle /dev/hwctr device sessions.
> */
> mutex_lock(&cfset_ctrset_mutex);
> - if (refcount_read(&cfset_opencnt)) {
> + if (refcount_read(&cfset_opencnt))
> cfset_offline_cpu(cpu);
> - cpum_cf_free_cpu(cpu);
> - }
> + cpum_cf_free(cpu);
[Severity: High]
Does this unconditional call to cpum_cf_free() permanently break CPU-bound
events when the CPU goes offline and comes back online?
CPU-bound events allocate infrastructure via cpum_cf_alloc() with a specific
CPU, taking the else branch which does not increment tskcnt:
arch/s390/kernel/perf_cpum_cf.c:cpum_cf_alloc() {
...
if (cpu == -1) {
...
if (!rc)
atomic_inc(&cpu_cf_root.tskcnt);
} else {
rc = cpum_cf_alloc_cpu(cpu);
}
...
}
When the CPU comes back online, cpum_cf_online_cpu() checks tskcnt:
arch/s390/kernel/perf_cpum_cf.c:cpum_cf_online_cpu() {
...
if (atomic_read(&cpu_cf_root.tskcnt))
rc = cpum_cf_alloc_cpu(cpu);
...
}
Since tskcnt was never incremented for the CPU-bound event, the
infrastructure is not reallocated. When the perf core attempts to restart the
event on the new CPU, cpumf_pmu_add() will return -ENODEV.
> mutex_unlock(&cfset_ctrset_mutex);
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803161651.3803702-1-tmricht@linux.ibm.com?part=1
prev parent reply other threads:[~2026-08-03 16:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 16:16 [PATCH] s390/cpum_cf: Handle CPU hotplug add and delete 6 Thomas Richter
2026-08-03 16:43 ` 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=20260803164318.E73BC1F000E9@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.