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 1:49 AM Zi Yan <ziy@nvidia.com> wrote:
>
> It seems that I reproduced it locally after enabling KASAN. And page owner
> seems to tell that it is KASAN code causing the issue. I added the patch
> below to dump_page() and dump_stack() when a freeing page’s private
> is not zero. It is on top of 6.19-rc7.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cbf758e27aa2..2151c847c35d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1402,6 +1402,10 @@ __always_inline bool free_pages_prepare(struct page *page,
>  #endif
>                 }
>                 for (i = 1; i < (1 << order); i++) {
> +                       if ((page + i)->private) {
> +                               dump_page(page + i, "non zero private");
> +                               dump_stack();
> +                       }
>                         if (compound)
>                                 bad += free_tail_page_prepare(page, page + i);
>                         if (is_check_pages_enabled()) {
>
> Kernel dump below says the page with non zero private was allocated
> in kasan_save_stack() and freed in kasan_save_stack().
>
> So fix kasan instead? ;)
>

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.

-- 
Best Regards,
Mike Gavrilov.