Re: [PATCH] arm64: smp: Limit nr_cpu_ids under nosmp

[zhangpengjie (A)]

Hi Catalin,

On 4/23/2026 1:16 AM, Catalin Marinas wrote:
> On Wed, Apr 22, 2026 at 05:58:31PM +0800, Pengjie Zhang wrote:
> > Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
> >
> > However, arm64 still enumerates firmware-described CPUs during SMP
> > initialization, so secondary CPUs can remain 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.
> >
> > Limit nr_cpu_ids to 1 in arch_disable_smp_support() so that
> > secondary CPUs are not set up on arm64 when nosmp/maxcpus=0 is in
> > effect.
> >
> > Signed-off-by: Pengjie Zhang <zhangpengjie2@xxxxxxxxxx>
> > ---
> >   arch/arm64/kernel/smp.c | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 1aa324104afb..cc34c68871e9 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -435,6 +435,15 @@ static void __init hyp_mode_check(void)
> >   	}
> >   }
> >   
> > +void __init arch_disable_smp_support(void)
> > +{
> > +	/*
> > +	 * Under nosmp/maxcpus=0, only the boot CPU can ever be brought up.
> > +	 * Limit nr_cpu_ids so that secondary CPUs are never set up.
> > +	 */
> > +	set_nr_cpu_ids(1);
> > +}
> I don't think that's the right fix. We don't have anything like the x86
> ioapic to disable in this function, so no need to implement it. If
> nr_cpu_ids must be 1 with nosmp/maxcpus=0, I'd rather do this in the
> generic code. It need some alignment with other architectures if we are
> to do this early. IOW, is nosmp equivalent to nr_cpus=1?
>
> In the meantime, for arm64, we can do something like below and let the
> generic code set nr_cpu_ids() via start_kernel() -> setup_nr_cpu_ids().

Thanks for the review. I completely agree with your assessment.

My initial thought was to consolidate the nosmp logic in one place,
but you are right—using `arch_disable_smp_support()` here is indeed
an abuse of the callback, as arm64 doesn't have SMP-specific hardware
to tear down like the x86 IOAPIC.

My main concern was specifically that under nosmp/maxcpus=0, secondary
CPUs can still remain visible to `for_each_possible_cpu()` users on
arm64, even though they will never reach the bringup path.

Regarding your question on whether `nosmp` is equivalent to `nr_cpus=1`:
practically, they both result in a uniprocessor system, but historically
they take different paths (`setup_max_cpus=0` vs early `nr_cpu_ids=1`).
Unifying this globally in generic code would indeed require a broader
cross-arch discussion, so your arm64-specific mitigation is the best
way forward right now.

Your proposed alternative in `smp_init_cpus()` is elegant and solves
the mask mismatch perfectly.

I will spin up a v2 incorporating your snippet and will add a
`Suggested-by` tag for you.

Thanks,
    Pengjie
> -------------8<-------------------
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 1aa324104afb..7364481cc03a 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -754,6 +754,13 @@ void __init smp_init_cpus(void)
>   		return;
>   	}
>
> +	/*
> +	 * For the nosmp/maxcpus=0 case, do not mark the secondary CPUs
> +	 * possible.
> +	 */
> +	if (!setup_max_cpus)
> +		return;
> +
>   	/*
>   	 * We need to set the cpu_logical_map entries before enabling
>   	 * the cpus so that cpu processor description entries (DT cpu nodes