Re: [PATCH v3 2/3] mm/page_alloc: only free healthy pages in high-order has_hwpoisoned folio

[Jiaqi Yan <jiaqiyan@google.com>]

Sorry for the late reply, Harry, Zi, Miaohe, and David. I was occupied
by some other duty in the past two weeks.

On Thu, Jan 15, 2026 at 12:43 PM David Hildenbrand (Red Hat)
<david@kernel.org> wrote:
>
> On 1/12/26 01:49, Jiaqi Yan wrote:
> > At the end of dissolve_free_hugetlb_folio(), a free HugeTLB folio
> > becomes non-HugeTLB, and it 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.
>
>
> Do we really have to have all that complexity in free_frozen_pages().
>
> Can't we hook into __update_and_free_hugetlb_folio() and just free the
> chunks there?

I don't know but I imagine to get chunks you will need the ability to
split a in-use (not free_huge_folio()-ed) hugetlb folio like splitting
a THP folio? Won't that be more complicated and very specific to
hugetlb? This solution is implemented in free_frozen_pages() to avoid
heavylifing splitting.

Also, doing in __update_and_free_hugetlb_folio() definitely won't help
with [1]: to handle a previously split-failed and now to be freed
PG_has_hwpoisoned THP. This solution works.

[1] https://lore.kernel.org/linux-mm/CACw3F529=PC-pwXOX0gbNrnS7HTwXq93oVT=V74J4FHLqcZ-ug@mail.gmail.com/T/#m202f91883b9b70c0346c3076db5b341d02d3f348

>
> >
> > Memory failure recovery (MFR) in kernel does attempt to take
> > raw HWPoison page off buddy allocator after
> > dissolve_free_hugetlb_folio(). However, there is always a time
> > window between dissolve_free_hugetlb_folio() frees a HWPoison
> > high-order folio to buddy allocator and MFR takes HWPoison
> > raw page off buddy allocator.
>
> I wonder whether marking the pageblock as isolated before freeing it
> could work?

Maybe... but where can the pageblock be isolated? Is there an existing
candidate, or inventing a scribble pad to stash it?

And then who and when should un-isolate the pageblock, if we don't
want to leak it?

>
> In that case, nobody will be able to allocate the page before we
> un-isolate it.
>
> Just a thought: but when you are dealing with a possible race, you can
> avoid that race by prohibiting the intermediate allocation from
> happening in the first place.
>
>
> Also, this is a lot of complexity. Was this issue already hit in the
> past or is it purely theoretical?

Theoretical for now. But when I work on [2] with William and Harry,
the issue can be reproduced fairly easily [3].

[2] https://lore.kernel.org/linux-mm/20251116013223.1557158-3-jiaqiyan@google.com/T/#m87c95ddf0b9397b409a9f8fac4e772ecc9abf209
[3] https://lore.kernel.org/linux-mm/20250919155832.1084091-1-william.roche@oracle.com


>
> --
> Cheers
>
> David