On Sat 14-07-18 09:39:29, Pavel Tatashin wrote: [...] > From 95259841ef79cc17c734a994affa3714479753e3 Mon Sep 17 00:00:00 2001 > From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx> > Date: Sat, 14 Jul 2018 09:15:07 -0400 > Subject: [PATCH] mm: zero unavailable pages before memmap init > > We must zero struct pages for memory that is not backed by physical memory, > or kernel does not have access to. > > Recently, there was a change which zeroed all memmap for all holes in e820. > Unfortunately, it introduced a bug that is discussed here: > > https://www.spinics.net/lists/linux-mm/msg156764.html > > Linus, also saw this bug on his machine, and confirmed that pulling > commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") > fixes the issue. > > The problem is that we incorrectly zero some struct pages after they were > setup. I am sorry but I simply do not see it. zero_resv_unavail should be touching only reserved memory ranges and those are not initialized anywhere. So who has reused them and put them to normal available memory to be initialized by free_area_init_node[s]? The patch itself should be safe because reserved and available memory ranges should be disjoint so the ordering shouldn't matter. The fact that it matters is the crux thing to understand and document. So the change looks good to me but I do not understand _why_ it makes any difference. There must be somebody to put (memblock) reserved memory available to the page allocator behind our backs. -- Michal Hocko SUSE Labs
