Re: [PATCH] mm/page_alloc: Fix freeing of failed-split poisoned compound pages

[Jiaqi Yan <jiaqiyan@google.com>]

On Fri, Jan 16, 2026 at 6:12 AM Boudewijn van der Heide
<boudewijn@delta-utec.com> wrote:
>
> Thanks Jiaqi for the feedback, that is very helpful.
> (and thanks Miaohe for connecting the issues.)
>
> After going through the memory_failure(),
> I can see it indeed puts the PG_HWPoison flag on the specific subpage pointer,
> and therefore my fix won't work as-is.
>
> > >
> > > Yes, this is also a problematic scenario for Hugetlb HugePage. And Jiaqi works on
> > > it now [1]. I think Jiaqi's patches might apply to THP scenario too. Add @Jiaqi to
> > > verify this.
> >
> > Yep, I think my work will also help solve the concern when
> > try_to_split_thp_page() fails.
>
> Your fix makes a lot of sense for hugetlb,
> as it linearly scans through all the pages.
> From my understanding,
> your fix also provides the perfect architecture for also checking THP,
> though it doesn't yet cover the in-use THP case outlined.

Oh, sorry I went ahead myself and assumed the split-failed folio would
eventually be released to the buddy allocator at some point when
userspace processes who owns/maps this THP are killed or exited.

Zi and Miaohe, am I right about this? or do we need explicitly handle
in-use and split-failed THP?

>
> For THP I would need to trace the failed-split paths more carefully,
> to check where the equivalent path for THP would be.
>
> If there is work needed for THP, I'm happy to help.
> Would you prefer I work on THP support as a separate follow-up patch,
> after yours is merged,
> or do you prefer to integrate it in your patch series?
>
> > >
> > > [1]: https://lore.kernel.org/all/20260112004923.888429-1-jiaqiyan@google.com/
> > >
> > > Thanks.
> > > .
>
> Thanks,
> Boudewijn