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

[Jiaqi Yan]

On Wed, Jul 22, 2026 at 2:03 AM Vlastimil Babka (SUSE)
<vbabka@xxxxxxxxxx> wrote:
>
> On 7/22/26 10:27, Vlastimil Babka (SUSE) 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.
> >
> > 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?
>
> Looking at the code, seems soft_offline_page() tries to take a refcount
> first and then sets the hwpoison flag, so it should be completely race-free
> wrt the page allocator.
>
> memory_failure() seems to start with TestSetPageHWPoison() and only then
> tries to get the refcount. Wonder if it should be that way.

Miaohe may correct me, but I think this diff between
soft_offline_page() and memory_failure() is intended.

soft_offline_page() is handling a still valid but soon may become
corrupted page. Its main goal is to gracefully migrate the still
perfectly valid data to a new page. We can only set the HWPoison bit
after (taking a refcount and) finishing migration.

memory_failure() is handling already hw corrupted data in the page, so
the top priority is to stop anyone from accessing the page, hence
TestSetPageHWPoison() should take precedence. Both get_hwpoison_page()
and get_huge_page_for_hwpoison() could be heavy and slow; generally we
can't tolerant the window between getting the refcount and marking
page toxic. In the worst case if someone re-accessed the corrupted
page, the 2nd Machine Check Exception would be fatal (if nested) and
bring down the system.

>
> > So assuming we don't just leave
> > 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?
> >
> >>    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.
> >
>