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: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/

>
>> 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.
> 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.
> The path is:
> 1. Page freed → free_pages_prepare() does NOT clear page->private
> 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?
>
> -- 
> Best Regards,
> Mike Gavrilov.


Best Regards,
Yan, Zi