[PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp

[zhangpengjie (A)]

On 4/30/2026 5:34 PM, zhangpengjie (A) wrote:
>
> On 4/27/2026 9:20 PM, Catalin Marinas wrote:
>> On Thu, Apr 23, 2026 at 09:46:54PM +0800, Pengjie Zhang wrote:
>>> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>>>
>>> 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.
>> I'm fine with the patch in principle but I fail to see why it is not
>> 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?
> 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.

I'm very sorry, there was an issue with the format above.
I'm reattaching the response below.

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.