Re: [PATCH v2 6.12 1/2] mm: replace free hugepage folios after migration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] mm/hugetlb: dequeue_hugetlb_folio_node_exact() skips isolated
  folios
- [Medium] mm: soft lockup in replace_free_hugepage_folios() on deferred
  HVO folios
- [Medium] mm/hugetlb: repeated dissolution of undissolved folio in
  replace_free_hugepage_folios()
--

commit 10e41795aa4490543b53bcfb3054aebb335f7640
Author: yangge <yangge1116@126.com>

mm: replace free hugepage folios after migration

This commit skips isolated free hugetlb folios during hugetlb pool
allocation and introduces replace_free_hugepage_folios() so free hugetlb
folios left behind after migration in alloc_contig_range_noprof() are
replaced and released to the buddy allocator.

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: High]
In mm/hugetlb.c at line 1354, does skipping MIGRATE_ISOLATE folios in
dequeue_hugetlb_folio_node_exact() break hugetlb reservation accounting
because those folios remain counted in h->free_huge_pages and
available_huge_pages(h)?

When free hugetlb folios sit in an isolated range, available_huge_pages(h)
still counts them as unreserved excess.  During migration in
alloc_hugetlb_folio_nodemask() (line 2441), dequeue_hugetlb_folio_node_exact()
skips the isolated free folios and instead dequeues non-isolated free
folios that were backing h->resv_huge_pages, leaving the freed old folio
queued in the isolated range.  In offline_pages(), a subsequent call to
dissolve_free_hugetlb_folios() dissolves the initial unreserved folios
until available_huge_pages(h) reaches 0 and then fails with -EBUSY in
dissolve_free_hugetlb_folio() (line 2230) after persistent hugepages have
already been dissolved.

In addition, when a task faults on a mapping with a valid reservation in
alloc_hugetlb_folio() (line 3105) while the free folios backing
h->resv_huge_pages are in a MIGRATE_ISOLATE pageblock,
dequeue_hugetlb_folio_vma() returns NULL and falls back to surplus
allocation, which fails with -ENOSPC (delivering SIGBUS) when overcommit
is disabled or the hstate is gigantic.

[Severity: Medium]
In mm/hugetlb.c at line 3022, can replace_free_hugepage_folios() loop on
 every tail PFN of the same hugetlb folio if
__update_and_free_hugetlb_folio() does not dissolve it into buddy pages?

After alloc_and_dissolve_hugetlb_folio() returns 0,
replace_free_hugepage_folios() advances start_pfn by 1 rather than
skipping the rest of the hugetlb folio.  When old_folio is
vmemmap-optimized and hugetlb_vmemmap_restore_folio() fails in
__update_and_free_hugetlb_folio() (line 1689), old_folio is put back on
the hugetlb freelist as a surplus compound folio via
add_hugetlb_folio(h, folio, true).  The subsequent tail PFNs resolve back
to the same old_folio via pfn_folio(start_pfn) and call
alloc_and_dissolve_hugetlb_folio() again, allocating extra replacement
hugepages and permanently inflating h->nr_huge_pages and
h->surplus_huge_pages.  Similarly, if an HVO folio has
HPG_raw_hwp_unreliable set (line 1681), __update_and_free_hugetlb_folio()
returns early with PG_hugetlb still set and HPG_freed clear, causing the
next PFN iteration to spin indefinitely in the
!folio_test_hugetlb_freed(old_folio) retry loop in
alloc_and_dissolve_hugetlb_folio() (line 2901).

[Severity: Medium]
In mm/page_alloc.c at line 6741, should alloc_contig_range_noprof() call
wait_for_freed_hugetlb_folios() before replace_free_hugepage_folios(start,
end)?

When HugeTLB vmemmap optimization (HVO) is enabled and
__alloc_contig_migrate_range() migrates an in-use hugetlb folio that is
freed to the buddy allocator (for example, when migrated to a temporary
folio or when surplus pages exist on the node),
update_and_free_hugetlb_folio() queues the old folio onto hpage_freelist
for free_hpage_work with PG_hugetlb still set, refcount 0, and HPG_freed
clear.  Because wait_for_freed_hugetlb_folios() is only called later in
test_pages_isolated() (mm/page_isolation.c, line 622),
replace_free_hugepage_folios() (mm/hugetlb.c, line 3022) passes that
deferred-free folio to alloc_and_dissolve_hugetlb_folio() (line 2901),
which busy-spins on !folio_test_hugetlb_freed(old_folio) taking and
dropping hugetlb_lock while free_hpage_workfn() sleeps in
synchronize_rcu(), and triggers a soft lockup if the caller is a
SCHED_FIFO or SCHED_RR task on the CPU where free_hpage_work was queued.

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