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

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

On Sat, Feb 7, 2026 at 3:16 AM Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> wrote:
>
> Hi Zi,
> Thanks for the deep investigation!
> So the actual culprit is KASAN's kasan_save_stack() leaving non-zero
> page->private.
> That explains why it only reproduces with KASAN enabled.
> Looking at the code, kasan_save_stack() doesn't seem to use
> page->private directly - it goes through stack_depot. Is stack_depot
> the actual culprit?
> Happy to help investigate further if needed.
> Regarding the fix location - even if we fix KASAN/stack_depot,
> split_page() clearing page->private still seems like the right
> defensive fix.
> The contract for split_page() is that it produces independent usable
> pages, and page->private being clean is part of that.
> Other code could potentially leave stale values too.
> I can share my .config if still needed, but it sounds like you've
> already reproduced it.
>

I think I found it. Looking at mm/internal.h:811, prep_compound_tail()
clears page->private for tail pages,
but it's only called for compound pages (__GFP_COMP).
Before commit 3b8000ae185c, vmalloc used __GFP_COMP, so tail pages got
their page->private cleared via prep_compound_tail().
After that commit dropped __GFP_COMP, tail pages keep stale values
from buddy allocator (which uses page->private for order).
So the stale value comes from buddy allocator's set_buddy_order() at
mm/page_alloc.c:755,
and __del_page_from_free_list() at line 898 only clears the head page's private.
This confirms the split_page() fix is the right place - it ensures
tail pages are properly initialized for independent use after
splitting.

-- 
Best Regards,
Mike Gavrilov.