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

[Jiaqi Yan]

On Wed, Jul 22, 2026 at 1:27 AM Vlastimil Babka (SUSE)
<vbabka@xxxxxxxxxx> wrote:
>
> On 7/17/26 15:06, William Roche wrote:
> > 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)
>
> Would it truly fix the issue, or rather there would still be a race window
> left where we check that there's no hwpoison flag in the re-enabled check,
> and only then someone sets it?
>
> Also, can the hardware actually detect a problem with a page that nobody
> accesses? I guess if yes, it's only in some corner cases.

Certain CPU's memory controller supports patrol scrubbing; most the
cases it corrects the correctable errors, and in some cases it signals
uncorrectable error, which could belong to free or allocated page(s).

>
> So I'm wary about penalizing the allocator paths again. If the page is in
> the buddy allocator, shouldn't it be isolated away as part of setting the
> hwpoison? I thought we already did that? So assuming we don't just leave

Yes - if is_free_buddy_page(p), memory_failure() will
take_page_off_buddy(p) after get_hwpoison_page().

> hwpoison pages in the buddy and this is only about some small race window
> where it's being taken away from the buddy? Then the extra check would only
> make a small window smaller, but is it worth it?

I agree that if we re-enable check_new_pages(), the window will be
smaller; because check_new_pages() can just check HWPoison bit and
don't need to wait for get_hwpoison_page() and take_page_off_buddy().

Worth it? Maybe not. There is still a window between handing out the
page and marking the page HWPoison. For example, when
ghes_do_memory_failure() handles memory error (typically on ARM64), it
either asks current to run memory_failure() when it exits kernel and
returns to userspace, or just queues memory_failure() to some cpu's
kworker thread. check_new_pages() may not even see __PG_HWPOISON if it
is racing against them.

That being said, my patch also won't help the issue above. My point is
if check_new_pages() is expensive but still can't work 100%, maybe not
workth it.

>
> >    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.
>