linux-kernel - Re: [PATCH v2] of_numa: fix uninitialized memory nodes causing kernel panic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aKF2VZ1y8OuEChmw@kernel.org>
Date: Sun, 17 Aug 2025 09:27:33 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Yin Tirui <yintirui@...wei.com>
Cc: robh@...nel.org, saravanak@...gle.com, dan.j.williams@...el.com,
	akpm@...ux-foundation.org, david@...hat.com,
	Jonathan.Cameron@...wei.com, devicetree@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	wangkefeng.wang@...wei.com, chenjun102@...wei.com
Subject: Re: [PATCH v2] of_numa: fix uninitialized memory nodes causing
 kernel panic

Hi,

On Sat, Aug 16, 2025 at 03:31:31PM +0800, Yin Tirui wrote:
> When the number of CPUs is fewer than the number of memory nodes,
> some memory nodes may not be properly initialized because they are
> not added to numa_nodes_parsed during memory parsing.

Why the issue happens when there are less CPUs than nodes?
Does anything updates numa_nodes_parsed when there are more CPUs than
nodes?
 
> In of_numa_parse_memory_nodes(), after successfully adding a memory
> block via numa_add_memblk(), the corresponding node ID should be
> marked as parsed. However, the current implementation in numa_add_memblk()

... current implementation of of_numa_parse_memory_nodes()?

> only adds the memory block to numa_meminfo but fails to update

maybe "... but skips updating"

> numa_nodes_parsed, leaving some nodes uninitialized.
> 
> During boot in a QEMU-emulated ARM64 NUMA environment, the kernel
> panics when free_area_init() attempts to access NODE_DATA() for
> memory nodes that were uninitialized.
> 
> [    0.000000] Call trace:
> [    0.000000]  free_area_init+0x620/0x106c (P)
> [    0.000000]  bootmem_init+0x110/0x1dc
> [    0.000000]  setup_arch+0x278/0x60c
> [    0.000000]  start_kernel+0x70/0x748
> [    0.000000]  __primary_switched+0x88/0x90

Would have be nice to have the full crash trace here and more details how
qemu was run.

> Cc: stable@...r.kernel.org
> Fixes: 767507654c22 ("arch_numa: switch over to numa_memblks")
> Signed-off-by: Yin Tirui <yintirui@...wei.com>
> 
> ---
> 
> v2: Move the changes to the of_numa related. Correct the fixes tag.
> ---
>  drivers/of/of_numa.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
> index 230d5f628c1b..cd2dc8e825c9 100644
> --- a/drivers/of/of_numa.c
> +++ b/drivers/of/of_numa.c
> @@ -59,8 +59,11 @@ static int __init of_numa_parse_memory_nodes(void)
>  			r = -EINVAL;
>  		}
>  
> -		for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++)
> +		for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++) {
>  			r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);
> +			if (!r)
> +				node_set(nid, numa_nodes_parsed);
> +		}
>  
>  		if (!i || r) {
>  			of_node_put(np);
> -- 
> 2.43.0
> 

-- 
Sincerely yours,
Mike.