Re: [PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp
From: zhangpengjie (A)
Date: Thu Apr 30 2026 - 05:35:11 EST
On 4/27/2026 9:20 PM, Catalin Marinas wrote:
On Thu, Apr 23, 2026 at 09:46:54PM +0800, Pengjie Zhang wrote:Yes, possible-but-not-present CPUs are valid in the general hotplug model. The nosmp/maxcpus=0 case is different though: on arm64, smp_prepare_cpus() treats this as a UP-mandated boot and returns before marking secondary CPUs present, so these CPUs are deliberately kept out of the bringup path for this boot. The kind of issue I had in mind was subsystem-owned per-CPU state where iteration follows cpu_possible_mask but the state is populated only from CPU online/probe paths. The CPPC nosmp issue fixed by commit 15eece6c5b05 ("ACPI: CPPC: Fix NULL pointer dereference when nosmp is used") was the kind of mismatch I was thinking of, although CPPC itself has already been fixed to use online CPUs where appropriate. I agree the changelog overstates this. I can respin with a toned-down changelog if you prefer.
Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.I'm fine with the patch in principle but I fail to see why it is not
However, arm64 still enumerates firmware-described CPUs during SMP
initialization, which can leave secondary CPUs visible to
for_each_possible_cpu() users even though they never reach the
bringup path in this configuration.
This is not just a cosmetic mask mismatch: code iterating over
possible CPUs may observe secondary CPU per-CPU state that is never
fully initialized under nosmp.
mostly cosmetic. If we have possible & !present CPUs (there's another
thread around cpuhp_smt_enable() to allow this combination on arm64),
get_cpu_device() would return NULL and the core code is supposed to
handle this. What other per-CPU state should be initialised for a
possible CPU but it is not without this patch?