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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

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@suse.cz
> 
> 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? 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.