Re: [RFC PATCH v3 03/13] LoongArch: Initialize CPU _PXM relation for disabled CPUs from SRAT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] loongarch/numa: skip adding disabled CPU node to numa_nodes_parsed
--

commit 9393724eb4ba65d5f1a0cdd15d60f325d36ffc28
Author: K Prateek Nayak <kprateek.nayak@amd.com>
Subject: LoongArch: Initialize CPU _PXM relation for disabled CPUs from SRAT

This commit updates SRAT parsing on LoongArch to initialize the CPU _PXM
(Node) relation even for disabled CPUs. This is intended to help early
topology parsing count LLC domains and set sparsebitmask properties, while
mapping per-CPU areas correctly.

> diff --git a/arch/loongarch/kernel/acpi.c b/arch/loongarch/kernel/acpi.c
> index cb454ee92b204..1f15f78713b7e 100644
> --- a/arch/loongarch/kernel/acpi.c
> +++ b/arch/loongarch/kernel/acpi.c
[ ... ]
> @@ -332,9 +331,12 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
>  		return;
>  	}
>  
> -	early_numa_add_cpu(pa->apic_id, node);
> -
>  	set_cpuid_to_node(pa->apic_id, node);
> +
> +	if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> +		return;
> +
> +	early_numa_add_cpu(pa->apic_id, node);
>  	node_set(node, numa_nodes_parsed);

[Severity: High]
Does skipping node_set() leave the NUMA node uninitialized?

If the node lacks memory and other enabled CPUs, it won't be added to
numa_nodes_parsed. As a result, alloc_node_data() will not be called,
leaving NODE_DATA(node) as NULL.

Since set_cpuid_to_node() was already called for this disabled CPU,
early_cpu_to_node() will return this uninitialized node instead of
NUMA_NO_NODE.

This can cause smp_prepare_boot_cpu() to bypass the safe rr_node fallback
and assign the uninitialized node to the CPU:

arch/loongarch/kernel/smp.c:smp_prepare_boot_cpu() {
    ...
		if (node != NUMA_NO_NODE)
			set_cpu_numa_node(cpu, node);
		else {
			set_cpu_numa_node(cpu, rr_node);
			rr_node = next_node_in(rr_node, node_online_map);
		}
    ...
}

Could this lead to generic per-CPU allocations or CPU hotplug actions blindly
dereferencing the NULL NODE_DATA(node) pointer? For example, when hotplugging
the disabled CPU:

mm/memory_hotplug.c:hotadd_init_pgdat() {
    ...
	pgdat = NODE_DATA(nid);

	/* init node's zones as empty zones, we don't have any present pages.*/
	if (free_area_init_core_hotplug(pgdat))
    ...
}

[ ... ]
> @@ -366,9 +367,12 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
>  		return;
>  	}
>  
> -	early_numa_add_cpu(pa->apic_id, node);
> -
>  	set_cpuid_to_node(pa->apic_id, node);
> +
> +	if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> +		return;
> +
> +	early_numa_add_cpu(pa->apic_id, node);
>  	node_set(node, numa_nodes_parsed);

[Severity: High]
Does this expose hotplugged CPUs in x2apic topologies to the same NULL
pointer dereference?

The exact same early return logic is present here for x2apic, skipping
the node_set() initialization for disabled CPUs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001192849.74788-1-kprateek.nayak@amd.com?part=3