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

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

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@huawei.com>
>> ---
>>   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
>
>