ACK/Cmnt: [SRU][R/N][PATCH 0/2] [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)

[Andrei Gherzan]

The "[UBUNTU 24.04]" tag is confusing given that this targets the Resolute
series as well.

On 26/09/03 09:01AM, Massimiliano Pellizzer via kernel-team wrote:
> BugLink: https://bugs.launchpad.net/bugs/2165732
> 
> [Impact]
> 
> s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks
> The command 'perf stat -e cycles -- <command>' crashes the kernel
> when CPUs are hotplug added during that run.
> 
> Root cause is the allocation of struct cpu_cf_events at first
> event initialization. The allocation is dynamic and the first
> event that has task context creates such a structure for
> each online CPU. This is not sufficient. CPUs may be offline
> during event creation and can be set online during the
> perf run time. For example commands
> 
>  # echo 0 > /sys/devices/system/cpu/cpu1/online
>  # perf stat -e cycles -i -- stress-ng -t10s --matrix X
>  # sleep 1
>  # echo 1 > /sys/devices/system/cpu/cpu1/online
> 
> create an event for CPUs 0,2-X. Since the events are created with
> task-context, the scheduler will eventually schedule the program
> on CPU1. This CPU has not created and initialized any per
> CPU event infrastructure as that CPU was not online at the time
> of the perf invocation. Thus when the scheduler runs stress-ng
> on CPU1, the function cpumf_pmu_add() refers to a NULL pointer:
> 
>  struct cpu_cf_events *cpuhw = this_cpu_cfhw();
> 
> This function call is invoked after the task stress-ng has been
> made runnable on CPU1. And this_cpu_cfhw() returns NULL.
> 
> The result is a panic.
> 
> The issue arises only in per-task context when the CPUMF facility is
> used and the scheduler picks a random CPU for such a process to run on.
> The scheduler enables the CPUMF infrastructure via PMU callback
> functions pmu::add() and pmu::del().
> 
> Introduce a CPU hotplug prepare/dead callback pair which creates and
> removes the per CPU counter data while the CPU is offline. Count the
> users which track every CPU (cpu == -1), that is perf_event_open()
> events with task context and /dev/hwctr device sessions, in the new
> counter cpu_cf_root::tskcnt, protected by pmc_reserve_mutex.
> This ensures the infrastructure is available when
> new CPU is selected to run the per-task context process.
> 
> In cpum_cf_free_root() and cpum_cf_free_cpu() ensure the reference
> pointer to data structures is set to NULL before the data is freed
> to prevent interrupt handlers to access stale data.
> 
> [Fix]
> 
> Backport commit:
> - 337bd95507a1 ("s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks")
> 
> [Test Plan]
> 
> Run the following commands:
> # echo 0 > /sys/devices/system/cpu/cpu1/online
> # perf stat -e cycles -i -- stress-ng -t10s --matrix X
> # sleep 1
> # echo 1 > /sys/devices/system/cpu/cpu1/online
> 
> [Regression Potential]
> 
> The change is confined to arch/s390/kernel/perf_cpum_cf.c,
> affecting only s390 systems using the CPU-Measurement Counter Facility PMU.
> It reworks locking and reference counting and adds two new CPU hotplug callbacks
> that now run on every hotplug transition on affected systems.
> A bookkeeping mismatch in the new tskctx counter or a lock-ordering error
> could reintroduce use-after-free or refcount bugs similar to the one being
> fixed.

Acked-by: Andrei Gherzan <andrei.gherzan at canonical.com>

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260903/33ed3eb8/attachment.sig>