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

[Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>]

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

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