Re: [PATCH v4 0/3] Only free healthy pages in high-order has_hwpoisoned folio

[Boudewijn van der Heide <boudewijn@delta-utec.com>]

Hi Jiaqi,
Thanks for including the THP scenario.

> Another similar situation is when a transparent huge page (THP)
> is handled by MFR but splitting failed. Such THP will eventually
> be released to buddy allocator when owning userspace processes
> are gone, but with certain subpages having HWPoison [9].

I think for failed-split THP, we need to do the following to support them:

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index cf0d526e6d41..3f727038f400 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -2479,6 +2479,7 @@ int memory_failure(unsigned long pfn, int flags)
 		if (err || new_order) {
 			/* get folio again in case the original one is split */
 			folio = page_folio(p);
+			folio_set_has_hwpoisoned(folio);
 			res = -EHWPOISON;
 			kill_procs_now(p, pfn, flags, folio);
 			put_page(p);

We set the PG_has_hwpoison flag here again, 
because when the split partially succeeds (new_order > 0),
page_folio(p) returns a new smaller-order folio that doesn't have the flag set. 
Without this, when the THP is eventually freed, 
free_pages_prepare() won't see the flag 
and HWPoison subpages could enter the buddy allocator. 

This aligns with what Miaohe mentioned in the earlier discussion [1]:

<quote Miaohe>

IMHO, it's enough to handle poisoned sub-pages when in-use or split-failed THP
eventually be released to the buddy.

</quote Miaohe>

Would you prefer to add this to your series,
or should I send a separate follow-up patch?

[1] https://lore.kernel.org/linux-mm/20260113205441.506897-1-boudewijn@delta-utec.com/

Kind regards,
Boudewijn