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

[William Roche]

On 7/17/26 12:18, David Hildenbrand (Arm) wrote:
> On 7/5/26 20:07, Jiaqi Yan wrote:
> > At the end of dissolve_free_hugetlb_folio(), a free HugeTLB
> > folio becomes non-HugeTLB and is released to buddy allocator
> > as a high-order folio, e.g. a folio that contains 262144 pages
> > if the folio was a 1G HugeTLB hugepage.
> >
> > This is problematic if the HugeTLB hugepage contained HWPoison
> > subpages. In that case, since buddy allocator does not check
> > HWPoison for non-zero-order folio, the raw HWPoison page can
> > be given out with its buddy page and be re-used by either
> > kernel or userspace.
>
> I still don't like the complexity of this, in particular, as we have different
> mechanisms in the page allocator already to try handling this,
>
> We also do have cases where we set the hwpoison bit, while a page is just about
> to get allocated from the buddy. So before we take it off the buddy, we might
> just hand out the page.
>
> check_new_pages() seems to check for PageHWPoison() and make us not hand out
> such pages. It's guarded by "check_pages" but it seems to do exactly what we are
> looking for, now?


Just adding a comment about this aspect:
The check_new_pages() mechanism used by the __rmqueue functions should
filter these pages out, but this has been disabled by default in 2023
with:
[PATCH] mm, page_alloc: reduce page alloc/free sanity checks
https://lore.kernel.org/all/20230216095131.17336-1-vbabka@xxxxxxx

So it would need to be enabled back, taking some of the performance hit.
(and I personally think that it has to be done)

  A note about the related project:
This patch is an addition to the "mm: memfd/hugetlb: introduce 
memfd-based userspace MFR policy"
project -- recycling the impacted hugetlb pages.

I do think that "memfd-based userspace MFR policy" is a valuable
enhancement, and if the impacted large page can be more easily recycled
enabling check_new_pages() it's even better !

HTH.