Re: Instability in current -git tree

[Pavel Tatashin <pasha.tatashin@oracle.com>]

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@oracle.com>
>> 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.

Now, I need to figure out what is happening with x86-32 failure, that is caused by my fix.

Pavel