[PATCH v2 0/2] mm/hugetlb: clear the hugetlb flag before leaking a hwpoisoned folio

[Mani Tofigh via B4 Relay]

If memory_failure() can't save the raw error page of a hugetlb folio,
the folio is marked raw_hwp_unreliable and leaked once it's freed.  With
hugetlb_free_vmemmap=on it's leaked while it's still a hugetlb folio,
and dissolving it then loops forever, e.g., when offlining its memory
block.  Patch 2 leaks it only after the hugetlb flag is cleared, as
without vmemmap optimization.

Miaohe pointed out that unpoison_memory() then doesn't see a hugetlb
folio anymore and unpoisons it.  That already happens without vmemmap
optimization, so patch 1 fixes it on its own and goes first.

Patch 2 lets a raw_hwp_unreliable folio reach the add_hugetlb_folio()
rollback when restoring its vmemmap fails, as
dissolve_free_hugetlb_folio() already does.  It relies on Kaitao's
"mm/hugetlb: preserve persistent flags when returning folios to the
pool" [1] (in mm-new) to keep the flag there.

Reproducer: https://github.com/manitofigh/files/blob/main/linux-repros/hugeoffline.c

[1] https://lore.kernel.org/all/20261102024910.31486-3-kaitao.cheng@xxxxxxxxx/

Changes in v2:
- New patch 1 so unpoison_memory() refuses the leaked folio (Miaohe).
- Patch 2: same code, added Fixes: bd225530a4c7 and fixed the commit
  message (offlining still retries until a signal).
- Rebased on mm-new.
- Link to v1: https://lore.kernel.org/all/20261028-hugetlb-hwpoison-leak-v1-1-77ce56002523@xxxxxxxxxxxx/

---
Mani Tofigh (2):
      mm/memory-failure: don't unpoison a leaked raw_hwp_unreliable folio
      mm/hugetlb: clear the hugetlb flag before leaking a hwpoisoned folio

 mm/hugetlb.c        | 15 ++++++++-------
 mm/memory-failure.c |  9 +++++++++
 2 files changed, 17 insertions(+), 7 deletions(-)
---
base-commit: 74d73ffcffe03804f97e9fb82301dadf75671282
change-id: 20261028-hugetlb-hwpoison-leak-b8d344361413

Best regards,
--  
Mani Tofigh <mt4022@xxxxxxxxxxxx>