Re: [PATCH] mm/page_alloc: clear page->private in split_page() for tail pages

[Zi Yan <ziy@nvidia.com>]

Hit send too soon, sorry about that.

On 6 Feb 2026, at 13:29, Zi Yan wrote:

> On 6 Feb 2026, at 13:21, Mikhail Gavrilov wrote:
>
>> Hi, Yan
>>
>> On Fri, Feb 6, 2026 at 11:08 PM Zi Yan <ziy@nvidia.com> wrote:
>>>
>>> Do you have a reproducer for this issue?
>>
>> Yes, I have a stress test that reliably reproduces the crash.
>> It cycles swapon/swapoff on 8GB zram under memory pressure:
>> https://gist.github.com/NTMan/4ed363793ebd36bd702a39283f06cee1

Got it.

Merging replies from Kairui from another email:

This patch is from previous discussion:
https://lore.kernel.org/linux-mm/CABXGCsO3XcXt5GDae7d74ynC6P6G2gLw3ZrwAYvSQ3PwP0mGXA@mail.gmail.com/

It looks odd to me too. That bug starts with vmalloc dropping
__GFP_COMP in commit 3b8000ae185c, because with __GFP_COMP, the
allocator does clean the ->private of tail pages on allocation with
prep_compound_page. Without __GFP_COMP, these ->private fields are
left as it is.

>>
>>> Last time I checked page->private usage, I find users clears ->private before free a page.
>>> I wonder which one I was missing.
>>
>> The issue is not about freeing - it's about allocation.

I assume everyone zeros used ->private, head or tail, so PageBuddy has
all zeroed ->private.

>> When buddy allocator merges/splits pages, it uses page->private to store order.
>> When a high-order page is later allocated and split via split_page(),
>> tail pages still have their old page->private values.

No, in __free_one_page(), if a free page is merged to a higher order,
it is deleted from free list and its ->private is zeroed. There should not
be any non zero private.

>> The path is:
>> 1. Page freed → free_pages_prepare() does NOT clear page->private

Right. The code assume page->private is zero for all pages, head or tail
if it is compound.

>> 2. Page goes to buddy allocator → buddy uses page->private for order
>> 3. Page allocated as high-order → post_alloc_hook() only clears head
>> page's private
>> 4. split_page() called → tail pages keep stale page->private
>>
>>> Clearing ->private in split_page() looks like a hack instead of a fix.
>>
>> I discussed this with Kairui Song earlier in the thread. We considered:
>>
>> 1. Fix in post_alloc_hook() - would need to clear all pages, not just head
>> 2. Fix in swapfile.c - doesn't work because stale value could
>> accidentally equal SWP_CONTINUED
>> 3. Fix in split_page() - ensures pages are properly initialized for
>> independent use
>>
>> The comment in vmalloc.c says split pages should be usable
>> independently ("some use page->mapping, page->lru, etc."), so
>> split_page() initializing the pages seems appropriate.
>>
>> But I agree post_alloc_hook() might be a cleaner place. Would you
>> prefer a patch there instead?

I think it is better to find out which code causes non zero ->private
at page free time.

Best Regards,
Yan, Zi