Re: [PATCH v6 0/5] Only free healthy pages in high-order has_hwpoisoned folio

[Vlastimil Babka (SUSE)]

On 7/22/26 10:27, Vlastimil Babka (SUSE) wrote:
> On 7/17/26 15:06, William Roche wrote:
>> On 7/17/26 12:18, David Hildenbrand (Arm) wrote:
>>> On 7/5/26 20:07, Jiaqi Yan wrote:
>>>> At the end of dissolve_free_hugetlb_folio(), a free HugeTLB
>>>> folio becomes non-HugeTLB and 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.
>>> 
>>> I still don't like the complexity of this, in particular, as we have different
>>> mechanisms in the page allocator already to try handling this,
>>> 
>>> We also do have cases where we set the hwpoison bit, while a page is just about
>>> to get allocated from the buddy. So before we take it off the buddy, we might
>>> just hand out the page.
>>> 
>>> check_new_pages() seems to check for PageHWPoison() and make us not hand out
>>> such pages. It's guarded by "check_pages" but it seems to do exactly what we are
>>> looking for, now?
>> 
>> 
>> Just adding a comment about this aspect:
>> The check_new_pages() mechanism used by the __rmqueue functions should
>> filter these pages out, but this has been disabled by default in 2023
>> with:
>> [PATCH] mm, page_alloc: reduce page alloc/free sanity checks
>> https://lore.kernel.org/all/20230216095131.17336-1-vbabka@xxxxxxx
>> 
>> So it would need to be enabled back, taking some of the performance hit.
>> (and I personally think that it has to be done)
> 
> Would it truly fix the issue, or rather there would still be a race window
> left where we check that there's no hwpoison flag in the re-enabled check,
> and only then someone sets it?
> 
> Also, can the hardware actually detect a problem with a page that nobody
> accesses? I guess if yes, it's only in some corner cases.
> 
> So I'm wary about penalizing the allocator paths again. If the page is in
> the buddy allocator, shouldn't it be isolated away as part of setting the
> hwpoison? I thought we already did that?

Looking at the code, seems soft_offline_page() tries to take a refcount
first and then sets the hwpoison flag, so it should be completely race-free
wrt the page allocator.

memory_failure() seems to start with TestSetPageHWPoison() and only then
tries to get the refcount. Wonder if it should be that way.

> So assuming we don't just leave
> hwpoison pages in the buddy and this is only about some small race window
> where it's being taken away from the buddy? Then the extra check would only
> make a small window smaller, but is it worth it?
> 
>>    A note about the related project:
>> This patch is an addition to the "mm: memfd/hugetlb: introduce 
>> memfd-based userspace MFR policy"
>> project -- recycling the impacted hugetlb pages.
>> 
>> I do think that "memfd-based userspace MFR policy" is a valuable
>> enhancement, and if the impacted large page can be more easily recycled
>> enabling check_new_pages() it's even better !
>> 
>> HTH.
>