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

[jane.chu@oracle.com]

On 8/4/2026 8:35 AM, Matthew Wilcox wrote:
> 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
> 
> 
> 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.
> 

First, I take back my comment about a pre-existing issue, because
folio_free_raw_hwp() does call if 
(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 
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 
PG_raw_hwp_unreliable is set is that, doing so would screw the 
validation tests and maybe some body's monitoring mechanism.
Had PG_raw_hwp_unreliable got set in a non-simulation scenario, 
immediately, OOM could happen, but then, we still lose the hugetlb folio 
for the remaining life of the kernel. Unless someone come up with a 
better solution to replace the raw_hwp_list. :)

thanks,
-jane