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

[Zi Yan <ziy@nvidia.com>]

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

> 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.

Hi Mikhail,

Do you mind sharing the kernel config? I am trying to reproduce it locally
but have no luck (Iteration 111 and going) so far.

Thanks.

Best Regards,
Yan, Zi