On Fri, Jul 13, 2018 at 5:47 PM Pavel Tatashin
<pasha.tatashin@xxxxxxxxxx> wrote:
>
> The commit intends to zero memmap (struct pages) for every hole in
> e820 ranges by marking them reserved in memblock. Later
> zero_resv_unavail() walks through memmap ranges and zeroes struct
> pages for every page that is reserved, but does not have a physical
> backing known by kernel.
Ahh. That just looks incoredibly buggy.
You can't just memset() the 'struct page' to zero after it's been set up.
That also zeroes page->flags, but page->flags contains things like the
zone and node ID.
That would explain the completely bogus "DMA" zone. That's not the
real zone, it's just that page_zonenr() returns 0 because of an
incorrect clearing of page->flags.
And it would also completely bugger pfn_to_page() for
CONFIG_DISCONTIGMEM, because the way that works is that it looks up
the node using page_to_nid(), and then looks up the pfn by using the
per-node pglist_data ->node_mem_map (that the 'struct page' is
supposed to be a pointer into).
So zerong the page->flags after it has been set up is completely wrong
as far as I can see. It literally invalidates 'struct page' and makes
various core VM function assumptions stop working.
As an example, it makes "page_to_pfn -> pfn_to_page" not be the
identity transformation, which could result in totally random
behavior.
And it definitely explains the whole "oh, now the zone ID doesn't
match" issue. It &*should* have been zone #1 ("DMA32"), but it got
cleared and that made it zone #0 ("DMA").
So yeah, this looks like the cause of it. And it could result in any
number of really odd problems, so this could easily explain the syzbot
failures and reboots at bootup too. Who knows what happens when
pfn_to_page() doesn't work any more.
Should we perhaps just revert
124049decbb1 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
f7f99100d8d9 mm: stop zeroing memory during allocation in vmemmap
it still reverts fairly cleanly (there's a trivial conflict with the
older commit).
Linus
