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

[Kairui Song <ryncsn@gmail.com>]

On Sat, Feb 7, 2026 at 2:08 AM Zi Yan <ziy@nvidia.com> wrote:
>
> +willy, david, and others included in Andrew’s mm-commit email.
>
> On 6 Feb 2026, at 12:40, Mikhail Gavrilov wrote:
>
> > When vmalloc allocates high-order pages and splits them via split_page(),
> > tail pages may retain stale page->private values from previous use by the
> > buddy allocator.
>
> Do you have a reproducer for this issue? Last time I checked page->private

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

> usage, I find users clears ->private before free a page. I wonder which one
> I was missing. The comment above page_private() does say ->private can
> be used on tail pages. If pages are freed with non-zero private in
> tail pages, we need to either correct the violating user or clear
> all pages ->private in post_alloc_hook() in addition to the head one.
> Clearing ->private in split_page() looks like a hack instead of a fix.

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.