Re: [PATCH] mm/page_alloc: Fix freeing of failed-split poisoned compound pages

[Miaohe Lin <linmiaohe@huawei.com>]

On 2026/1/14 22:48, Boudewijn van der Heide wrote:
>>> free_pages_prepare() only handles poisoned order-0 pages.
>>> In memory_failure() (hard offline), pages
>>> are poisoned before attempting to split huge pages. If the split fails,
>>> the page remains a compound (order > 0) but is already poisoned. However,
>>> Soft-offline pages are always poisoned as order-0 after migration, so
>>> they are unaffected.
>>>
>>> The '!order' check causes these poisoned compound pages to skip
>>> poison handling, leaving them in the buddy allocator.
>>>
>>> Worst case, a poisoned compound page could be reallocated,
>>> potentially leading to crashes, silent data corruption,
>>> or unwanted memory containment actions before the poison bit is detected.
>>>
>>> This patch removes the '&& !order' restriction. Cleanup functions in the
>>> poison-handling block correctly handle non-zero order pages, making
>>> this change safe.
> 
>> This is not a fix. IIUC, for >0 order free pages, memory failure uses
>> take_page_off_buddy() in a different code path.
>>
> 
> Thanks again for the quick response and clarification! 
>>From my understanding, 
> you correctly noted that take_page_off_buddy() handles already-free pages, 
> removing them from the buddy lists and setting SetPageHWPoisonTakenOff(). 
> This prevents those pages from re-entering the buddy allocator.

Thanks both.

> 
> My concern is about in-use THP-backed compound pages:
> 1. A compound page is in use. 
> 2. memory_failure() marks it poisoned (TestSetPageHWPoison).
> 3. try_to_split_thp_page() fails.
> 4. The process using the THP may be killed; 
>         the page remains compound and poisoned.
> 5. Later, when the page is finally freed, it reaches free_pages_prepare();
>         'take_page_off_buddy()' is not invoked in this path.

Yes, this is also a problematic scenario for Hugetlb HugePage. And Jiaqi works on
it now [1]. I think Jiaqi's patches might apply to THP scenario too. Add @Jiaqi to
verify this.

[1]: https://lore.kernel.org/all/20260112004923.888429-1-jiaqiyan@google.com/

Thanks.
.