On 6/18/19 5:37 PM, Michael Ellerman wrote:
Vaibhav Jain <vaib...@linux.ibm.com> writes:
We recently discovered an bug where physical memory meant for
allocation of Huge-pages was inadvertently allocated by another component
during early boot.
Can you give me some more detail on what that was? You're seemingly the
only person who's ever hit this :)
The behavior of memblock_reserve() where it wont
indicate whether an existing reserved block overlaps with the
requested reservation only makes such bugs hard to investigate.
Hence this patch proposes adding a memblock reservation check in
htab_dt_scan_hugepage_blocks() just before call to memblock_reserve()
to ensure that the physical memory thats being reserved for is not
already reserved by someone else. In case this happens we panic the
the kernel to ensure that user of this huge-page doesn't accidentally
stomp on memory allocated to someone else.
Do we really need to panic? Can't we just leave the block alone and not
register it as huge page memory? With a big warning obviously.
I need to check this again with Paul. But IIRC we have issues w.r.t hash
page table size, if we use 16G pages as 64K mapped pages. ie, hypervisor
create hash page table size with the assumptions that these pfns will
only be mapped as 16G pages. If we try to put 64K hash pte entries for
them we will not have enough space in hash page table.
That is one of the reason we never allowed freeing the hugetlb reserved
pool with 16G pages back to buddy.
Note: We should switch that BUG to panic. I guess using BUG that early
don't work.
-aneesh
