Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()

From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	tj@kernel.org, bp@alien8.de, linux-kernel@vger.kernel.org
Subject: Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()
Date: Thu, 6 Apr 2017 15:44:59 +0300	[thread overview]
Message-ID: <20170406124459.dwn5zhpr2xqg3lqm@node.shutemov.name> (raw)
In-Reply-To: <20170314030801.13656-2-richard.weiyang@gmail.com>

On Tue, Mar 14, 2017 at 11:08:01AM +0800, Wei Yang wrote:
> numa_nodemask_from_meminfo() is called to set bit according to
> numa_meminfo. While the only two places for this call is used to set proper
> bit to a copy of numa_nodes_parsed from numa_meminfo. With current code
> path, those numa node information in numa_meminfo is a subset of
> numa_nodes_parsed. So it is not necessary to set the bits again.
> 
> The following is a code path analysis to prove the numa node information in
> numa_meminfo is a subset of numa_nodes_parsed.
> 
>     x86_numa_init()
>         numa_init()
>             Case 1
>             acpi_numa_init()
>                 acpi_parse_memory_affinity()
>                     numa_add_memblk()
>                     node_set(numa_nodes_parsed)
>                 acpi_parse_slit()
>                     numa_nodemask_from_meminfo()
> 
>             Case 2
>             amd_numa_init()
>                 numa_add_memblk()
>                 node_set(numa_nodes_parsed)
> 
>             Case 3
>             dummy_numa_init()
>                 node_set(numa_nodes_parsed)
>                 numa_add_memblk()
> 
>             numa_register_memblks()
>                 numa_nodemask_from_meminfo()
> 
> From the code path analysis, we can see each time a memblk is added, the
> proper bit is set in numa_nodes_parsed, which means it is not necessary to
> set it again in numa_nodemask_from_meminfo() for a copy of
> numa_nodes_parsed.
> 
> This patch removes numa_nodemask_from_meminfo().
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>

I've got the crash below on master/tip. Reveting the patch helps.

================================================================================
UBSAN: Undefined behaviour in /home/kas/linux/la57/mm/sparse.c:336:9
member access within null pointer of type 'struct pglist_data'
CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-rc5-00604-gf03eaf0479bc #5084
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
 dump_stack+0x84/0xb8
 ubsan_epilogue+0x12/0x3f
 __ubsan_handle_type_mismatch+0x80/0x1a0
 sparse_early_usemaps_alloc_node+0x45/0x1b0
 alloc_usemap_and_memmap+0x37b/0x390
 ? alloc_usemap_and_memmap+0x390/0x390
 ? memblock_virt_alloc_try_nid+0xa4/0xb7
 ? 0xffffffff81000000
 sparse_init+0x5e/0x31a
 ? 0xffffffff81000000
 ? 0xffffffff81000000
 paging_init+0x18/0x27
 setup_arch+0xc92/0xe67
 ? early_idt_handler_array+0x120/0x120
 start_kernel+0x63/0x4e3
 x86_64_start_reservations+0x2a/0x2c
 x86_64_start_kernel+0x171/0x180
 secondary_startup_64+0x9f/0x9f
================================================================================
BUG: unable to handle kernel paging request at 0000000000021a40
IP: sparse_early_usemaps_alloc_node+0x45/0x1b0
PGD 0
P4D 0

Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-rc5-00604-gf03eaf0479bc #5084
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
task: ffffffff82615280 task.stack: ffffffff82600000
RIP: 0010:sparse_early_usemaps_alloc_node+0x45/0x1b0
RSP: 0000:ffffffff82603cf8 EFLAGS: 00010082
RAX: 0000000000000002 RBX: 0000000000000800 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000001
RBP: ffffffff82603d40 R08: 3d3d3d3d3d3d3d3d R09: 3d3d3d3d3d3d3d3d
R10: 000000000401b000 R11: 3d3d3d3d3d3d3d3d R12: 0000000000000050
R13: ffff88087bbdf000 R14: 0000000000000000 R15: 0000000000000050
FS:  0000000000000000(0000) GS:ffffffff8333f000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000021a40 CR3: 000000000540a000 CR4: 00000000000006b0
Call Trace:
 alloc_usemap_and_memmap+0x37b/0x390
 ? alloc_usemap_and_memmap+0x390/0x390
 ? memblock_virt_alloc_try_nid+0xa4/0xb7
 ? 0xffffffff81000000
 sparse_init+0x5e/0x31a
 ? 0xffffffff81000000
 ? 0xffffffff81000000
 paging_init+0x18/0x27
 setup_arch+0xc92/0xe67
 ? early_idt_handler_array+0x120/0x120
 start_kernel+0x63/0x4e3
 x86_64_start_reservations+0x2a/0x2c
 x86_64_start_kernel+0x171/0x180
 secondary_startup_64+0x9f/0x9f
Code: c1 e3 05 48 83 ec 20 48 89 55 c0 e8 1b 36 f1 fd 4e 8b 34 f5 00 95 31 83 4d 85 f6 75 0e 31 f6 48 c7 c7 e0 92 96 82 e8 e0 bf 5b fe <45> 8b 86 40 1a 02 00 31 c9 31 d2 31 f6 48 89 df e8 b9 e4 ff ff
RIP: sparse_early_usemaps_alloc_node+0x45/0x1b0 RSP: ffffffff82603cf8
CR2: 0000000000021a40
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Fatal exception

-- 
 Kirill A. Shutemov