<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><style>body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 10.5pt; font-family: 微软雅黑; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><body>
<div><span></span></div><div><span><div style="MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"><div style="font-family: 宋体; color: rgb(128, 128, 128); font-size: 10.5pt; font-weight: bold;">Thanks a lot.We have added the patch into the kernel4.0-rc4 and it works.</div></div></span></div>
<blockquote style="margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"><div> </div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style="PADDING-RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From:</b> <a href="mailto:khlebnikov@yandex-team.ru">Konstantin Khlebnikov</a></div><div><b>Date:</b> 2015-04-29 16:30</div><div><b>To:</b> <a href="mailto:songxiumiao@inspur.com">songxiumiao@inspur.com</a>; <a href="mailto:robherring2@gmail.com">Rob Herring</a></div><div><b>CC:</b> <a href="mailto:grant.likely@linaro.org">Grant Likely</a>; <a href="mailto:devicetree@vger.kernel.org">devicetree@vger.kernel.org</a>; <a href="mailto:robh+dt@kernel.org">Rob Herring</a>; <a href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a>; <a href="mailto:sparclinux@vger.kernel.org">sparclinux@vger.kernel.org</a>; <a href="mailto:linux-mm@kvack.org">linux-mm@kvack.org</a>; <a href="mailto:linuxppc-dev@lists.ozlabs.org">linuxppc-dev</a>; <a href="mailto:yanxiaofeng@inspur.com">yanxiaofeng</a>; <a href="mailto:x86@kernel.org">x86@kernel.org</a>; <a href="mailto:linux-metag@vger.kernel.org">linux-metag@vger.kernel.org</a></div><div><b>Subject:</b> Re: [PATCH] of: return NUMA_NO_NODE from fallback of_node_to_nid()</div></div></div><div><div>+x86@kernel.org</div>
<div>+linux-metag@vger.kernel.org</div>
<div> </div>
<div>here is proposed fix:</div>
<div>https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg864009.html</div>
<div> </div>
<div>It returns NUMA_NO_NODE from both static-inline (CONFIG_OF=n) and weak</div>
<div>version of of_node_to_nid(). This change might affect few arches which</div>
<div>whave CONFIG_OF=y but doesn't implement of_node_to_nid() (i.e. depends</div>
<div>on default behavior of weak function). It seems this is only metag.</div>
<div> </div>
<div> From mm/ point of view returning NUMA_NO_NODE is a right choice when</div>
<div>code have no idea which numa node should be used -- memory allocation</div>
<div>functions choose current numa node (but they might use any).</div>
<div> </div>
<div>On 29.04.2015 04:11, songxiumiao@inspur.com wrote:</div>
<div>> When we test the cpu and memory hotplug feature in the server with x86</div>
<div>> architecture and kernel4.0-rc4,we met the similar problem.</div>
<div>></div>
<div>> The situation is that when memory in node0 is offline,the system is down</div>
<div>> during booting.</div>
<div>></div>
<div>> Following is the bug information:</div>
<div>> [ 0.335176] BUG: unable to handle kernel paging request at</div>
<div>> 0000000000001b08</div>
<div>> [ 0.342164] IP: [<ffffffff81182587>] __alloc_pages_nodemask+0xb7/0x940</div>
<div>> [ 0.348706] PGD 0</div>
<div>> [ 0.350735] Oops: 0000 [#1] SMP</div>
<div>> [ 0.353993] Modules linked in:</div>
<div>> [ 0.357063] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc4 #1</div>
<div>> [ 0.363232] Hardware name: Inspur TS860/TS860, BIOS TS860_2.0.0</div>
<div>> 2015/03/24</div>
<div>> [ 0.370095] task: ffff88085b1e0000 ti: ffff88085b1e8000 task.ti:</div>
<div>> ffff88085b1e8000</div>
<div>> [ 0.377564] RIP: 0010:[<ffffffff81182587>] [<ffffffff81182587>]</div>
<div>> __alloc_pages_nodemask+0xb7/0x940</div>
<div>> [ 0.386524] RSP: 0000:ffff88085b1ebac8 EFLAGS: 00010246</div>
<div>> [ 0.391828] RAX: 0000000000001b00 RBX: 0000000000000010 RCX:</div>
<div>> 0000000000000000</div>
<div>> [ 0.398953] RDX: 0000000000000000 RSI: 0000000000000000 RDI:</div>
<div>> 00000000002052d0</div>
<div>> [ 0.406075] RBP: ffff88085b1ebbb8 R08: ffff88085b13fec0 R09:</div>
<div>> 000000005b13fe01</div>
<div>> [ 0.413198] R10: ffff88085e807300 R11: ffffffff810d4bc1 R12:</div>
<div>> 000000000001002a</div>
<div>> [ 0.420321] R13: 00000000002052d0 R14: 0000000000000001 R15:</div>
<div>> 00000000000040d0</div>
<div>> [ 0.427446] FS: 0000000000000000(0000) GS:ffff88085ee00000(0000)</div>
<div>> knlGS:0000000000000000</div>
<div>> [ 0.435522] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033</div>
<div>> [ 0.441259] CR2: 0000000000001b08 CR3: 00000000019ae000 CR4:</div>
<div>> 00000000001406f0</div>
<div>> [ 0.448382] Stack:</div>
<div>> [ 0.450392] ffff88085b1e0000 0000000000000400 ffff88085b1effff</div>
<div>> ffff88085b1ebb68</div>
<div>> [ 0.457846] 000000000000007b ffff88085b12d140 ffff88085b249000</div>
<div>> 000000000000007b</div>
<div>> [ 0.465298] ffff88085b1ebb28 ffffffff81af2900 0000000000000000</div>
<div>> 002052d05b12d140</div>
<div>> [ 0.472750] Call Trace:</div>
<div>> [ 0.475206] [<ffffffff811d27b3>] ? deactivate_slab+0x383/0x400</div>
<div>> [ 0.481123] [<ffffffff811d3947>] new_slab+0xa7/0x460</div>
<div>> [ 0.486174] [<ffffffff816789e5>] __slab_alloc+0x310/0x470</div>
<div>> [ 0.491655] [<ffffffff8105304f>] ? dmar_msi_set_affinity+0x8f/0xc0</div>
<div>> [ 0.497921] [<ffffffff810d4bc1>] ? __irq_domain_add+0x41/0x100</div>
<div>> [ 0.503838] [<ffffffff810d0fee>] ? irq_do_set_affinity+0x5e/0x70</div>
<div>> [ 0.509920] [<ffffffff811d571d>] __kmalloc_node+0xad/0x2e0</div>
<div>> [ 0.515483] [<ffffffff810d4bc1>] ? __irq_domain_add+0x41/0x100</div>
<div>> [ 0.521392] [<ffffffff810d4bc1>] __irq_domain_add+0x41/0x100</div>
<div>> [ 0.527133] [<ffffffff8105102e>] mp_irqdomain_create+0x9e/0x120</div>
<div>> [ 0.533140] [<ffffffff81b2fb14>] setup_IO_APIC+0x64/0x1be</div>
<div>> [ 0.538622] [<ffffffff81b2e226>] apic_bsp_setup+0xa2/0xae</div>
<div>> [ 0.544099] [<ffffffff81b2bc70>] native_smp_prepare_cpus+0x267/0x2b2</div>
<div>> [ 0.550531] [<ffffffff81b1927b>] kernel_init_freeable+0xf2/0x253</div>
<div>> [ 0.556625] [<ffffffff8166b960>] ? rest_init+0x80/0x80</div>
<div>> [ 0.561845] [<ffffffff8166b96e>] kernel_init+0xe/0xf0</div>
<div>> [ 0.566979] [<ffffffff81681bd8>] ret_from_fork+0x58/0x90</div>
<div>> [ 0.572374] [<ffffffff8166b960>] ? rest_init+0x80/0x80</div>
<div>> [ 0.577591] Code: 30 97 00 89 45 bc 83 e1 0f b8 22 01 32 01 01 c9 d3</div>
<div>> f8 83 e0 03 89 9d 6c ff ff ff 83 e3 10 89 45 c0 0f 85 6d 01 00 00 48 8b</div>
<div>> 45 88 <48> 83 78 08 00 0f 84 51 01 00 00 b8 01 00 00 00 44 89 f1 d3 e0</div>
<div>> [ 0.597537] RIP [<ffffffff81182587>] __alloc_pages_nodemask+0xb7/0x940</div>
<div>> [ 0.604158] RSP <ffff88085b1ebac8></div>
<div>> [ 0.607643] CR2: 0000000000001b08</div>
<div>> [ 0.610962] ---[ end trace 0a600c0841386992 ]---</div>
<div>> [ 0.615573] Kernel panic - not syncing: Fatal exception</div>
<div>> [ 0.620792] ---[ end Kernel panic - not syncing: Fatal exception</div>
<div>> *From:* Rob Herring <mailto:robherring2@gmail.com></div>
<div>> *Date:* 2015-04-14 00:49</div>
<div>> *To:* Konstantin Khlebnikov <mailto:khlebnikov@yandex-team.ru></div>
<div>> *CC:* Grant Likely <mailto:grant.likely@linaro.org>;</div>
<div>> devicetree@vger.kernel.org <mailto:devicetree@vger.kernel.org>; Rob</div>
<div>> Herring <mailto:robh+dt@kernel.org>; linux-kernel@vger.kernel.org</div>
<div>> <mailto:linux-kernel@vger.kernel.org>; sparclinux@vger.kernel.org</div>
<div>> <mailto:sparclinux@vger.kernel.org>; linux-mm@kvack.org</div>
<div>> <mailto:linux-mm@kvack.org>; linuxppc-dev</div>
<div>> <mailto:linuxppc-dev@lists.ozlabs.org></div>
<div>> *Subject:* Re: [PATCH] of: return NUMA_NO_NODE from fallback</div>
<div>> of_node_to_nid()</div>
<div>> On Mon, Apr 13, 2015 at 8:38 AM, Konstantin Khlebnikov</div>
<div>> <khlebnikov@yandex-team.ru> wrote:</div>
<div>> > On 13.04.2015 16:22, Rob Herring wrote:</div>
<div>> >></div>
<div>> >> On Wed, Apr 8, 2015 at 11:59 AM, Konstantin Khlebnikov</div>
<div>> >> <khlebnikov@yandex-team.ru> wrote:</div>
<div>> >>></div>
<div>> >>> Node 0 might be offline as well as any other numa node,</div>
<div>> >>> in this case kernel cannot handle memory allocation and crashes.</div>
<div>> >>></div>
<div>> >>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru></div>
<div>> >>> Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function")</div>
<div>> >>> ---</div>
<div>> >>> drivers/of/base.c | 2 +-</div>
<div>> >>> include/linux/of.h | 5 ++++-</div>
<div>> >>> 2 files changed, 5 insertions(+), 2 deletions(-)</div>
<div>> >>></div>
<div>> >>> diff --git a/drivers/of/base.c b/drivers/of/base.c</div>
<div>> >>> index 8f165b112e03..51f4bd16e613 100644</div>
<div>> >>> --- a/drivers/of/base.c</div>
<div>> >>> +++ b/drivers/of/base.c</div>
<div>> >>> @@ -89,7 +89,7 @@ EXPORT_SYMBOL(of_n_size_cells);</div>
<div>> >>> #ifdef CONFIG_NUMA</div>
<div>> >>> int __weak of_node_to_nid(struct device_node *np)</div>
<div>> >>> {</div>
<div>> >>> - return numa_node_id();</div>
<div>> >>> + return NUMA_NO_NODE;</div>
<div>> >></div>
<div>> >></div>
<div>> >> This is going to break any NUMA machine that enables OF and expects</div>
<div>> >> the weak function to work.</div>
<div>> ></div>
<div>> ></div>
<div>> > Why? NUMA_NO_NODE == -1 -- this's standard "no-affinity" signal.</div>
<div>> > As I see powerpc/sparc versions of of_node_to_nid returns -1 if they</div>
<div>> > cannot find out which node should be used.</div>
<div>> Ah, I was thinking those platforms were relying on the default</div>
<div>> implementation. I guess any real NUMA support is going to need to</div>
<div>> override this function. The arm64 patch series does that as well. We</div>
<div>> need to be sure this change is correct for metag which appears to be</div>
<div>> the only other OF enabled platform with NUMA support.</div>
<div>> In that case, then there is little reason to keep the inline and we</div>
<div>> can just always enable the weak function (with your change). It is</div>
<div>> slightly less optimal, but the few callers hardly appear to be hot</div>
<div>> paths.</div>
<div>> Rob</div>
<div>> --</div>
<div>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in</div>
<div>> the body of a message to majordomo@vger.kernel.org</div>
<div>> More majordomo info at http://vger.kernel.org/majordomo-info.html</div>
<div>> Please read the FAQ at http://www.tux.org/lkml/</div>
<div> </div>
<div> </div>
<div>-- </div>
<div>Konstantin</div>
</div></blockquote>
</body></html>