LKML Archive on lore.kernel.org
 help / color / Atom feed
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
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

  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14  3:08 [Patch V2 1/2] x86/mm/numa: trivial fix on typo and error message Wei Yang
2017-03-14  3:08 ` [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo() Wei Yang
2017-04-03  9:58   ` [tip:x86/mm] x86/mm/numa: Remove numa_nodemask_from_meminfo() tip-bot for Wei Yang
2017-04-06 12:44   ` Kirill A. Shutemov [this message]
2017-04-06 14:59     ` [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo() Borislav Petkov
2017-04-06 15:42       ` Kirill A. Shutemov
2017-04-06 18:01         ` Borislav Petkov
2017-04-06 18:21           ` Kirill A. Shutemov
2017-04-06 18:48             ` Borislav Petkov
2017-04-09  3:12               ` Wei Yang
2017-04-10 12:43                 ` Borislav Petkov
2017-04-10 16:39                   ` Wei Yang
2017-04-03  9:57 ` [tip:x86/mm] x86/mm/numa: Improve alloc_node_data() error path message tip-bot for Wei Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170406124459.dwn5zhpr2xqg3lqm@node.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=richard.weiyang@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git