Re: [PATCH v3 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/hugetlb: repeated dissolution of undissolved folio in
  replace_free_hugepage_folios()
- [Medium] mm: soft lockup in replace_free_hugepage_folios() on deferred
  HVO folios
--

commit 5faa426035efacd066fe63acf72c80b50a32aaee
Author: yangge <yangge1116@126.com>

mm: replace free hugepage folios after migration

This commit adds replace_free_hugepage_folios() after migration in
alloc_contig_range_noprof() to replace free hugetlb folios in the isolated
range with newly allocated folios, and skips MIGRATE_ISOLATE folios in
dequeue_hugetlb_folio_node_exact().

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 is_migrate_isolate_page() in
dequeue_hugetlb_folio_node_exact() break hugetlb reservation accounting while
isolated free folios remain counted in h->free_huge_pages?

available_huge_pages(h) computes h->free_huge_pages - h->resv_huge_pages and
still counts free folios in MIGRATE_ISOLATE pageblocks as available.  When
offline_pages() or alloc_contig_range_noprof() migrates an in-use hugetlb
folio while unreserved free folios exist in the isolated range and reserved
free folios exist outside it, alloc_hugetlb_folio_nodemask() sees
available_huge_pages(h) > 0, skips the isolated free folios in
dequeue_hugetlb_folio_node_exact(), and consumes a non-isolated free folio
that was backing h->resv_huge_pages, leaving the newly freed source folio on
the freelist inside the isolated range.

In offline_pages(), dissolve_free_hugetlb_folios() then dissolves the earlier
isolated folios until h->free_huge_pages drops to h->resv_huge_pages, and
dissolve_free_hugetlb_folio() fails with -EBUSY on the remaining isolated
folio after persistent hugepages have already been dissolved.  Likewise, when
free folios backing h->resv_huge_pages sit in a MIGRATE_ISOLATE range,
dequeue_hugetlb_folio_vma() in alloc_hugetlb_folio() and
alloc_hugetlb_folio_reserve() skip them; when nr_overcommit_huge_pages is 0
or the hstate is gigantic, alloc_hugetlb_folio() fails with -ENOSPC and
delivers SIGBUS to a process faulting on a reserved mapping.

[Severity: Medium]
In mm/hugetlb.c at lines 3022-3030, can advancing start_pfn by 1 in
replace_free_hugepage_folios() repeatedly call
alloc_and_dissolve_hugetlb_folio() on every tail PFN of an undissolved
compound hugetlb folio?

When old_folio is vmemmap-optimized, remove_hugetlb_folio() leaves PG_hugetlb
set until __update_and_free_hugetlb_folio() restores its vmemmap.  If
hugetlb_vmemmap_restore_folio() fails under memory pressure,
__update_and_free_hugetlb_folio() puts old_folio back onto the hugetlb
freelist via add_hugetlb_folio(h, folio, true) as a surplus hugepage while
alloc_and_dissolve_hugetlb_folio() still returns 0.  Because start_pfn only
advances by 1, the remaining (1 << huge_page_order(h)) - 1 tail PFNs resolve
to the same old_folio via pfn_folio(start_pfn) and invoke
alloc_and_dissolve_hugetlb_folio() again, allocating extra replacement
hugepages and permanently inflating h->nr_huge_pages and
h->surplus_huge_pages.

If a vmemmap-optimized folio instead has HPG_raw_hwp_unreliable set,
__update_and_free_hugetlb_folio() returns early with PG_hugetlb still set and
HPG_freed cleared, so the next PFN iteration spins forever on
!folio_test_hugetlb_freed(old_folio) in alloc_and_dissolve_hugetlb_folio().
In addition, if old_folio gains a reference before hugetlb_lock is taken in
alloc_and_dissolve_hugetlb_folio(), isolate_hugetlb() isolates it onto
isolate_list and putback_movable_pages(&isolate_list) immediately puts it
back onto hugepage_activelist without migrating it.

[Severity: Medium]
In mm/page_alloc.c at line 6751, can calling replace_free_hugepage_folios()
before wait_for_freed_hugetlb_folios() in alloc_contig_range_noprof() spin on
hugetlb_lock or trigger a soft lockup when HVO is enabled?

When __alloc_contig_migrate_range() migrates an in-use HVO hugetlb folio that
is freed to the buddy system (for example when migrated to a temporary folio
or when surplus hugepages exist on the node), free_huge_folio() leaves
PG_hugetlb set with refcount 0 and HPG_freed cleared, queues the folio on
hpage_freelist, and schedules free_hpage_work.  Because
replace_free_hugepage_folios() runs before test_pages_isolated() calls
wait_for_freed_hugetlb_folios() (even with the later fix in commit
"mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb
folios"), replace_free_hugepage_folios() sees folio_test_hugetlb(folio) and
!folio_ref_count(folio) and calls alloc_and_dissolve_hugetlb_folio().

In alloc_and_dissolve_hugetlb_folio() at line 2901, !folio_test_hugetlb_freed()
is true, so it loops acquiring and releasing hugetlb_lock with cond_resched()
while free_hpage_workfn() sleeps in synchronize_rcu() during vmemmap
restoration.  If the caller is a SCHED_FIFO or SCHED_RR task on the same CPU
where schedule_work(&free_hpage_work) queued the work item, cond_resched()
never yields to the SCHED_NORMAL kworker thread and locks up the CPU.
Calling wait_for_freed_hugetlb_folios() before replace_free_hugepage_folios()
would drain hpage_freelist first.

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