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

On 8/4/2026 8:35 AM, Matthew Wilcox wrote:
> On Mon, Aug 03, 2026 at 11:=E2=80=8A40:=E2=80=8A25PM -0700, jane.=E2=80=
=8Achu@=E2=80=8Aoracle.=E2=80=8Acom=20
> wrote: > Patch itself looks good, so Reviewed-by: Jane Chu <jane.=E2=80=
=8Achu@=E2=80=8A=20
> oracle.=E2=80=8Acom> Thanks! > That said, there is a pre-existing issue: =
>=20
> folio_free_raw_hwp() should check
>=20
>=20
> On Mon, Aug 03, 2026 at 11:40:25PM -0700, [email protected] wrote:
>> Patch itself looks good, so Reviewed-by: Jane Chu <[email protected]>
>=20
> Thanks!
>=20
>> That said, there is a pre-existing issue:
>> folio_free_raw_hwp() should check HPG_raw_hwp_unreliable, and fail the a=
ct
>> of unpoison just like what __update_and_free_hugetlb_folio() does -
>>=20
>> static void __update_and_free_hugetlb_folio(struct hstate *h,
>>                                                 struct folio *folio)
>> {
>>         bool clear_flag =3D folio_test_hugetlb_vmemmap_optimized(folio);
>>=20
>>         if (hstate_is_gigantic_no_runtime(h))
>>                 return;
>>=20
>>         /*
>>          * 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;
>=20
> I'm not sure I agree with that, but I'm new to hugetlb & hwpoison
> handling, so please check my reasoning.
>=20
> 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.
>=20
> Maybe there's more to it than that.
>=20

First, I take back my comment about a pre-existing issue, because
folio_free_raw_hwp() does call if=20
(folio_test_hugetlb_raw_hwp_unreliable(folio)) and bail out if true,
before it calls __folio_free_raw_hwp() to dissolve the list.
So, apology for the false alarm.

Also agreed with you that once a non-simulated hwpoison occurs, unpoison=20
will be disallowed for the remaining life time of the kernel.

But I think the reason we don't dissolve the raw_hwp_list if=20
PG_raw_hwp_unreliable is set is that, doing so would screw the=20
validation tests and maybe some body's monitoring mechanism.
Had PG_raw_hwp_unreliable got set in a non-simulation scenario,=20
immediately, OOM could happen, but then, we still lose the hugetlb folio=20
for the remaining life of the kernel. Unless someone come up with a=20
better solution to replace the raw_hwp_list. :)

thanks,
-jane