Re: [PATCH v3 2/3] mm/page_alloc: only free healthy pages in high-order has_hwpoisoned folio

[David Hildenbrand (Red Hat)]

On 1/12/26 01:49, Jiaqi Yan wrote:
> At the end of dissolve_free_hugetlb_folio(), a free HugeTLB folio
> becomes non-HugeTLB, and it 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.


Do we really have to have all that complexity in free_frozen_pages().

Can't we hook into __update_and_free_hugetlb_folio() and just free the 
chunks there?

> Memory failure recovery (MFR) in kernel does attempt to take
> raw HWPoison page off buddy allocator after
> dissolve_free_hugetlb_folio(). However, there is always a time
> window between dissolve_free_hugetlb_folio() frees a HWPoison
> high-order folio to buddy allocator and MFR takes HWPoison
> raw page off buddy allocator.

I wonder whether marking the pageblock as isolated before freeing it 
could work?

In that case, nobody will be able to allocate the page before we 
un-isolate it.

Just a thought: but when you are dealing with a possible race, you can 
avoid that race by prohibiting the intermediate allocation from 
happening in the first place.


Also, this is a lot of complexity. Was this issue already hit in the 
past or is it purely theoretical?

--
Cheers

David