Re: [PATCH v8 02/15] memory-failure: Prevent hugetlb freeing during unpoisoning

[Matthew Wilcox <willy@infradead.org>]

On Mon, Aug 03, 2026 at 11:40:25PM -0700, jane.chu@oracle.com wrote:
> Patch itself looks good, so Reviewed-by: Jane Chu <jane.chu@oracle.com>

Thanks!

> That said, there is a pre-existing issue:
> folio_free_raw_hwp() should check HPG_raw_hwp_unreliable, and fail the act
> of unpoison just like what __update_and_free_hugetlb_folio() does -
> 
> static void __update_and_free_hugetlb_folio(struct hstate *h,
>                                                 struct folio *folio)
> {
>         bool clear_flag = folio_test_hugetlb_vmemmap_optimized(folio);
> 
>         if (hstate_is_gigantic_no_runtime(h))
>                 return;
> 
>         /*
>          * If we don't know which subpages are hwpoisoned, we can't free
>          * the hugepage, so it's leaked intentionally.
>          */
>         if (folio_test_hugetlb_raw_hwp_unreliable(folio))
>                 return;

I'm not sure I agree with that, but I'm new to hugetlb & hwpoison
handling, so please check my reasoning.

We set the unreliable bit when memory allocation fails (ie we can't
allocate a raw_hwp_page).  That does mean that if we have a real hardware
error, we can't know which page was poisoned, but for a simulated hwpoison
which we are now clearing, it doesn't matter which page specifically
contained the hwpoison.  We're going to unpoison all of the pages in
this hugetlb folio anyway.

Maybe there's more to it than that.