On Mon, May 6, 2019 at 10:40 PM Sasha Levin <sas...@kernel.org> wrote: > > From: Michal Hocko <mho...@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.shteynf...@gmail.com> > Fixes: 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the > full memory section") > Cc: sta...@kernel.org > Signed-off-by: Michal Hocko <mho...@suse.com> > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> > Signed-off-by: Sasha Levin <alexander.le...@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