On Tue, 1 Dec 2020 20:15:02 +0200 Mike Rapoport <rppt@xxxxxxxxxx> wrote: > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > There could be struct pages that are not backed by actual physical memory. > This can happen when the actual memory bank is not a multiple of > SECTION_SIZE or when an architecture does not register memory holes > reserved by the firmware as memblock.memory. > > Such pages are currently initialized using init_unavailable_mem() function > that iterated through PFNs in holes in memblock.memory and if there is a > struct page corresponding to a PFN, the fields if this page are set to > default values and it is marked as Reserved. > > init_unavailable_mem() does not take into account zone and node the page > belongs to and sets both zone and node links in struct page to zero. > > On a system that has firmware reserved holes in a zone above ZONE_DMA, for > instance in a configuration below: > > # grep -A1 E820 /proc/iomem > 7a17b000-7a216fff : Unknown E820 type > 7a217000-7bffffff : System RAM > > unset zone link in struct page will trigger > > VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page); That sounds pretty serious. > because there are pages in both ZONE_DMA32 and ZONE_DMA (unset zone link in > struct page) in the same pageblock. > > Interleave initialization of pages that correspond to holes with the > initialization of memory map, so that zone and node information will be > properly set on such pages. > Should this be backported to -stable? If so, do we have a suitable Fixes:?
