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

[Zi Yan <ziy@nvidia.com>]

On 6 Feb 2026, at 18:06, Zi Yan wrote:

> On 6 Feb 2026, at 17:37, Mikhail Gavrilov wrote:
>
>> 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.
>
> set_buddy_order() also only set head page’s private. And at each buddy
> page merge, any buddy found in free list gets its head page’s private
> cleared in __del_page_from_free_list(). The final merged free page
> gets its private set by set_buddy_order() at done_merging. There should
> not be any stale values in any page’s private, if I read the code correctly.
>
> If it is the problem of buddy allocator leaving stale private values,
> the problem would be reproducible with and without KASAN.
>

OK, it seems that both slub and shmem do not reset ->private when freeing
pages/folios. And tail page's private is not zero, because when a page
with non zero private is freed and gets merged with a lower buddy, its
private is not set to 0 in the code path.

The patch below seems to fix the issue, since I am at Iteration 104 and counting.
I also put a VM_BUG_ON(page->private) in free_pages_prepare() and it is not
triggered either.


diff --git a/mm/shmem.c b/mm/shmem.c
index ec6c01378e9d..546e193ef993 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2437,8 +2437,10 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
 failed_nolock:
 	if (skip_swapcache)
 		swapcache_clear(si, folio->swap, folio_nr_pages(folio));
-	if (folio)
+	if (folio) {
+		folio->swap.val = 0;
 		folio_put(folio);
+	}
 	put_swap_device(si);

 	return error;
diff --git a/mm/slub.c b/mm/slub.c
index f77b7407c51b..2cdab6d66e1a 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3311,6 +3311,7 @@ static void __free_slab(struct kmem_cache *s, struct slab *slab)

 	__slab_clear_pfmemalloc(slab);
 	page->mapping = NULL;
+	page->private = 0;
 	__ClearPageSlab(page);
 	mm_account_reclaimed_pages(pages);
 	unaccount_slab(slab, order, s);



But I am not sure if that is all. Maybe the patch below on top is needed to find all violators
and still keep the system running. I also would like to hear from others on whether page->private
should be reset or not before free_pages_prepare().

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cbf758e27aa2..9058f94b0667 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1430,6 +1430,8 @@ __always_inline bool free_pages_prepare(struct page *page,

 	page_cpupid_reset_last(page);
 	page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
+	VM_WARN_ON_ONCE(page->private);
+	page->private = 0;
 	reset_page_owner(page, order);
 	page_table_check_free(page, order);
 	pgalloc_tag_sub(page, 1 << order);


--
Best Regards,
Yan, Zi