Re: [PATCHv6 08/17] mm: Make page_zonenum() use head page

[Frank van der Linden]

On Mon, Feb 23, 2026 at 11:32 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 2/23/26 19:18, Matthew Wilcox wrote:
> > On Mon, Feb 16, 2026 at 10:06:57AM +0100, David Hildenbrand (Arm) wrote:
> >> On 2/16/26 00:13, Matthew Wilcox wrote:
> >>>
> >>> You're right that different pages in the same folio can have different
> >>> zone number.  But does it matter ... or to put it another way, why is
> >>> returning the zone number of the head page the correct way to resolve
> >>> this?
> >>
> >> How can a folio cross zones?
> >
> > I thought 1GB pages in hugetlb could cross zones?  Maybe that used to be
> > true and isn't any more, or maybe it was never true and I was just
> > confused.
>
> I recall that 1G folios could end up in ZONE_MOVABLE (comment in
> page_is_unmovable()), but my memory is fuzzy when it comes to crossing
> zones (ZONE_NORMAL -> ZONE_MOVABLE).
>
> Freeing+reinitializing the vmemmap for HVO with such folios would
> already be problematic I suppose: we would silently switch the zone for
> some of these pages.
>
> When freeing such (boottime) hugetlb folios to the buddy, we use
> free_frozen_pages(). In there we lookup the zone once.
>
> Likely also problematic :)

HugeTLB folios weren't supposed to cross zones, but they could do that
in some cases for bootmem (memblock) allocated pages, causing the
issue you describe.

I fixed that with 14ed3a595fa4 ("mm/hugetlb: check bootmem pages for
zone intersections"), so they won't cross zones anymore. The other
allocation methods used for HugeTLB folios, alloc_contig_pages() and
cma_alloc_folio, won't return anything that crosses a zone boundary by
their nature.

So I think that's all good.

- Frank