Re: [PATCH 6.1] mm: replace free hugepage folios after migration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] mm: hugetlb: skipping isolated free pages in
  dequeue_huge_page_node_exact() breaks reservation accounting
- [Medium] mm: omitted replace_free_hugepage_folios() leaves cma_alloc()
  broken
--

commit dac0c7128f296db4178dac403221b3262724e8f6
Author: yangge <yangge1116@126.com>

mm: replace free hugepage folios after migration

This backport of upstream commit 04f13d241b8b146b23038bffd907cb8278391d07
updates dequeue_huge_page_node_exact() in mm/hugetlb.c to skip free hugepages
located in MIGRATE_ISOLATE pageblocks so that isolated free hugepages are not
reused during migration.

Link: https://lkml.kernel.org/r/1734503588-16254-1-git-send-email-yangge1116@126.com
Link: https://lkml.kernel.org/r/1736582300-11364-1-git-send-email-yangge1116@126.com

[Severity: Medium]
The commit title and changelog describe introducing and calling
replace_free_hugepage_folios() after migrating in-use hugetlb pages in
__alloc_contig_migrate_range(), but this 6.1 backport only keeps the
is_migrate_isolate_page(page) check in dequeue_huge_page_node_exact() at
mm/hugetlb.c:1347.

In __alloc_contig_migrate_range() at mm/page_alloc.c:9231, when an in-use
hugetlb page in the target range [start, end) is migrated while
available_huge_pages(h) > 0 and a non-isolated free hugepage exists on
h->hugepage_freelists, alloc_migration_target() -> alloc_huge_page_nodemask()
dequeues that persistent pool page without HPageTemporary set. When migration
completes, free_huge_page() at mm/hugetlb.c:1978 enqueues the old source page
back onto h->hugepage_freelists[nid] instead of freeing it to the buddy
allocator.

Because replace_free_hugepage_folios() was omitted from this backport (even
though 6.1 already has __alloc_contig_migrate_range() in mm/page_alloc.c and
alloc_and_dissolve_huge_page() in mm/hugetlb.c), the old source page remains a
PageHuge page rather than PageBuddy inside [start, end). Won't
test_pages_isolated() in alloc_contig_range() at mm/page_alloc.c:9366 and the
!PageBuddy(pfn_to_page(outer_pfn)) check in isolate_single_pageblock() at
mm/page_isolation.c:439 still fail with -EBUSY, leaving the cma_alloc()
failure described in the commit message unresolved?

[Severity: High]
In dequeue_huge_page_node_exact() at mm/hugetlb.c:1347, skipping pages where
is_migrate_isolate_page(page) is true leaves those isolated free hugepages on
h->hugepage_freelists[nid] and still counted in h->free_huge_pages.

However, available_huge_pages() at mm/hugetlb.c:1397 still computes
h->free_huge_pages - h->resv_huge_pages without discounting isolated free
hugepages. Can this cause two regressions in reservation accounting?

First, when a free hugepage backing h->resv_huge_pages lies in a
MIGRATE_ISOLATE pageblock (either isolated in place by
start_isolate_page_range() during offline_pages() or alloc_contig_range(), or
placed there after migration), a page fault on a VMA with a valid reservation
calls hugetlb_no_page() -> alloc_huge_page() at mm/hugetlb.c:3139 ->
dequeue_huge_page_vma() -> dequeue_huge_page_node_exact(). Because
dequeue_huge_page_node_exact() skips the isolated page, dequeue_huge_page_vma()
returns NULL and alloc_huge_page() falls back to
alloc_buddy_huge_page_with_mpol() -> alloc_surplus_huge_page() at
mm/hugetlb.c:2456. When h->surplus_huge_pages >= h->nr_overcommit_huge_pages
(which is 0 by default) or hstate_is_gigantic(h), alloc_huge_page() returns
ERR_PTR(-ENOSPC), delivering SIGBUS to a process faulting on a reserved mapping.

Second, during offline_pages(), suppose an unreserved free hugepage H0 is in
the MIGRATE_ISOLATE range (for example, after an in-use hugepage H0 was
migrated to an unreserved pool page and freed via free_huge_page() ->
enqueue_huge_page()) and another free hugepage F2 outside the isolated range
backs a reservation (h->free_huge_pages == 2, h->resv_huge_pages == 1).
Because H0 is still counted in h->free_huge_pages, available_huge_pages(h)
remains 1. When migrating a second in-use hugepage H1 via
alloc_huge_page_nodemask() at mm/hugetlb.c:2546 (or during a concurrent
unreserved fault in dequeue_huge_page_vma() at mm/hugetlb.c:1417),
available_huge_pages(h) is non-zero, so dequeue_huge_page_nodemask() is called,
skips the isolated H0 in dequeue_huge_page_node_exact(), and consumes the
non-isolated reserved page F2 instead of falling back to
alloc_migrate_huge_page(). H1 is then freed onto h->hugepage_freelists inside
the isolated range, leaving only isolated pages on the freelist to back
h->resv_huge_pages. When offline_pages() subsequently calls
dissolve_free_huge_pages() -> dissolve_free_huge_page() at mm/hugetlb.c:2359,
won't it dissolve H0 and then fail on H1 with -EBUSY because
!available_huge_pages(h)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105070346.3099207-1-mkbund@amazon.com?part=1