On Mon 16-07-18 08:09:19, Pavel Tatashin wrote: > > > On 07/16/2018 08:06 AM, Michal Hocko wrote: > > 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. > > Thats exactly right, and I am also not sure why this is happening, > there must be some overlapping happening that just should not. I will > study it later. Maybe a stupid question, but I do not see it from the code (this init code is just to complex to keep it cached in head so I always have to study the code again and again, sigh). So what exactly prevents memmap_init_zone to stumble over reserved regions? We do play some ugly games to find a first !reserved pfn in the node but I do not really see anything in the init path to properly skip over reserved holes inside the node. -- Michal Hocko SUSE Labs
