On Mon, May 6, 2019 at 10:40 PM Sasha Levin sashal@kernel.org wrote:
From: Michal Hocko mhocko@suse.com
[ Upstream commit 4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a ]
This reverts commit 2830bf6f05fb3e05bc4743274b806c821807a684.
The underlying assumption that one sparse section belongs into a single numa node doesn't hold really. Robert Shteynfeld has reported a boot failure. The boot log was not captured but his memory layout is as follows:
Early memory node ranges node 1: [mem 0x0000000000001000-0x0000000000090fff] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff] node 1: [mem 0x0000000100000000-0x0000001423ffffff] node 0: [mem 0x0000001424000000-0x0000002023ffffff]
This means that node0 starts in the middle of a memory section which is also in node1. memmap_init_zone tries to initialize padding of a section even when it is outside of the given pfn range because there are code paths (e.g. memory hotplug) which assume that the full worth of memory section is always initialized.
In this particular case, though, such a range is already intialized and most likely already managed by the page allocator. Scribbling over those pages corrupts the internal state and likely blows up when any of those pages gets used.
Reported-by: Robert Shteynfeld robert.shteynfeld@gmail.com Fixes: 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the full memory section") Cc: stable@kernel.org Signed-off-by: Michal Hocko mhocko@suse.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin alexander.levin@microsoft.com
mm/page_alloc.c | 12 ------------ 1 file changed, 12 deletions(-)
So it looks like you already had the revert of the earlier patch I pointed out enqueued as well. So you can probably at a minimum just drop this patch and the earlier patch that this reverts.
Thanks.
- Alex