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

["zhangpengjie (A)" <zhangpengjie2@huawei.com>]

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.