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

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

[Pengjie Zhang]

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.

Return early from smp_init_cpus() when nosmp/maxcpus=0 is in effect
so that secondary CPUs are not marked possible on arm64.

Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
---
Changes in v2:
- Drop the arch_disable_smp_support() approach.
- Handle nosmp/maxcpus=0 directly in smp_init_cpus().
- Update the changelog accordingly.
Link to v1:https://lore.kernel.org/all/20260422095831.2926775-1-zhangpengjie2@huawei.com/

---
 arch/arm64/kernel/smp.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1aa324104afb..1b63846f646a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -745,15 +745,21 @@ void __init smp_init_cpus(void)
 	else
 		acpi_parse_and_init_cpus();
 
-	if (cpu_count > nr_cpu_ids)
-		pr_warn("Number of cores (%d) exceeds configured maximum of %u - clipping\n",
-			cpu_count, nr_cpu_ids);
-
 	if (!bootcpu_valid) {
 		pr_err("missing boot CPU MPIDR, not enabling secondaries\n");
 		return;
 	}
 
+	/*
+	 * For the nosmp/maxcpus=0 case, do not mark the secondary CPUs
+	 * possible.
+	 */
+	if (!setup_max_cpus)
+		return;
+
+	if (cpu_count > nr_cpu_ids)
+		pr_warn("Number of cores (%d) exceeds configured maximum of %u - clipping\n",
+			cpu_count, nr_cpu_ids);
 	/*
 	 * We need to set the cpu_logical_map entries before enabling
 	 * the cpus so that cpu processor description entries (DT cpu nodes
-- 
2.33.0

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

[Catalin Marinas]

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?

-- 
Catalin

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

[zhangpengjie (A)]

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.

Re: [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.

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

[Catalin Marinas]

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>