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

[Catalin Marinas <catalin.marinas@arm.com>]

On Thu, Apr 30, 2026 at 05:54:35PM +0800, zhangpengjie (A) wrote:
> 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.

Please do. Since it's not an urgent fix, I'll leave it for 7.2. With the
commit text changed:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>