A crash on ARM64 in move_freepages_block due to uninitialized pages in reserved memory

[will.deacon@arm.com (Will Deacon)]

On Thu, Aug 30, 2018 at 11:58:19AM -0400, Mikulas Patocka wrote:
> On Wed, 29 Aug 2018, James Morse wrote:
> > HOLES_IN_ZONE is similar, if some memory is smaller than MAX_ORDER_NR_PAGES,
> > possibly due to nomap holes.
> > 
> > 6d526ee26ccd only enabled it for NUMA systems on arm64, because the NUMA code
> > was first to fall foul of this, but there is nothing NUMA specific about nomap
> > holes within a MAX_ORDER_NR_PAGES region.
> > 
> > I'm convinced arm64 should always enable HOLES_IN_ZONE because nomap pages can
> > occur anywhere. I'll post a fix.
> 
> But x86 had the same bug -
> https://bugzilla.redhat.com/show_bug.cgi?id=1598462

Yeah, that's not readable and lkml.org is down. Any idea what x86 did?

> And x86 fixed it without enabling HOLES_IN_ZONE. On x86, the BIOS can also 
> reserve any memory range - so you can have arbitrary holes there that are 
> not predictable when the kernel is compiled.

What happens when the BIOS reserves a page on x86? Is it still mapped by
the kernel (and therefore has a valid struct page) or is it treated like
NOMAP?

> Currently HOLES_IN_ZONE is selected only for ia64, mips/octeon - so does 
> it mean that all the other architectures don't have holes in the memory 
> map?

Possibly. Note also that arm64 already selects HOLES_IN_ZONE if NUMA.

> What should be architecture-independent way how to handle the holes?

Until firmware is architecture-independent, I think handling this
generically is a lost cause.

Will