Re: [PATCH v2 0/5] Keep tail page private zero at free and folio split time

["Zi Yan" <ziy@nvidia.com>]

On Fri Jul 3, 2026 at 9:47 AM EDT, Zi Yan wrote:
> Hi all,
>
> This patchset makes sure tail_page->private is zero before compound or
> high-order pages are returned to the allocator. It also checks tail pages
> that become new folio heads during large folio split, before their private
> fields are used by new folios.
>
> It is based on mm-new.
>
> Note on ZONE_DEVICE and DAX page/folio
> ===
> ZONE_DEVICE and DAX use prep_compound_tail() to reinitialize folios, so
> tail_page->private was reset before this patchset. There was a concern that
> after this patchset stale ->private can appear after ZONE_DEVICE/DAX folio
> initialization. My reasoning is that no code sets ZONE_DEVICE/DAX
> page->private, so their page->private stays zero all the time.
> ZONE_DEVICE_PRIVATE page migration only supports anonymous memory without
> swapcache, so after the migration ->private remains zero.
>
> But let me know if my reasoning is wrong. It can be fixed by adding
> ->private zeroing code in ZONE_DEVICE/DAX folio initialization code.
>
> Motivation
> ===
>
> page->private is zeroed at page free time since commit ac1ea219590c0
> ("mm/page_alloc: clear page->private in free_pages_prepare()"), since we
> concluded that it might be too much to ask every page user to free a page
> with ->private zeroed. The holder of the last page reference might not know
> whether ->private needs to be cleared.
>
> For compound and high-order pages, tail_page->private can also leak to
> later users if it is left uncleared. The page allocation path does not zero
> every tail_page->private field, so they can be seen by new users and cause
> unexpected issues[1].
>
> Check tail_page->private at page free time, and check tail pages that
> become new folio heads during large folio split. With those checks in
> place, prep_compound_tail() no longer needs to clear tail_page->private
> when preparing compound page metadata.
>
> Overview
> ===
>
> 1. Patch 1 clears all pages ->private before percpu-km frees them.
> 2. Patch 2 removes setting page->private in compaction code when a free
>    page is taken out of the buddy allocator. cc->freepages is indexed by
>    page order, so storing the free page order in page->private is
>    redundant. In alloc_contig_frozen_range_noprof(),
>    isolate_freepages_range() is used to grab free pages from buddy
>    allocator and it leaves the aforementioned page->private set until
>    either split_free_frozen_pages() or prep_new_page() is called. That
>    stale value without resetting triggers the tail_page->private nonzero
>    check once set_page_private(0) is removed from prep_compound_tail().
>
> 3. Patch 3 adds back the page->private check for tail pages promoted to new
>    folio heads in __split_folio_to_order().
> 4. Patch 4 adds a tail_page->private check in the page free path.
> 5. Patch 5 removes tail_page->private zeroing from prep_compound_tail().
>
> Link: https://lore.kernel.org/all/20260206174017.128673-1-mikhail.v.gavrilov@gmail.com/ [1]
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
> Changes in v2:
> 1. added reset page->private when percpu-km frees pages
> 2. replaced subpage with tail page/tail_page in all patches
> 3. moved implementation details from cc->freepages patch message to cover
>    letter, since it is too much for a patch description.
> 4. used VM_WARN_ON_ONCE_PAGE() in __split_folio_to_order() patch without
>    fixup. The expectation is to catch any violation during development
>    phase.
> 5. guarded tail_page->private check behind is_check_pages_enabled().
> 6. replaced tail_page->private reset code with VM_WARN_ON_ONCE() instead of
>    deletion in prep_compound_tail
> 7. the pre-existing issue in alloc_contig_frozen_range_noprof() is under
>    discussion and might not be worth fixing.
>    - Link: https://lore.kernel.org/all/d44ae8a5-ec70-456b-92a0-ce7ccabf6917@kernel.org/
> - Link to v1: https://lore.kernel.org/r/20260628-keep-subpage-private-zero-at-free-v1-0-f4ce3930d10f@nvidia.com
>
> ---
> Zi Yan (5):
>       mm/percpu-km: clear page->private before free them
>       mm/compaction: stop recording free page order in page->private
>       mm/huge_memory: add page->private check back in __split_folio_to_order()
>       mm/page_alloc: make sure tail_page->private is zero at page free time
>       mm/page_alloc: remove set_page_private() in prep_compound_tail()
>
>  mm/compaction.c  |  3 ---
>  mm/huge_memory.c |  7 +++++++
>  mm/internal.h    |  2 +-
>  mm/page_alloc.c  | 13 ++++++++++---
>  mm/percpu-km.c   |  9 ++++++++-
>  5 files changed, 26 insertions(+), 8 deletions(-)
> ---
> base-commit: e031e55776cf9193b4720a253e92539ca536d224
> change-id: 20260603-keep-subpage-private-zero-at-free-a1e1435025dc
>
> Best regards,

Answers to Sashiko's reviews:
https://sashiko.dev/#/patchset/20260703-keep-subpage-private-zero-at-free-v2-0-2970fe777dd6%40nvidia.com

Q1: To Patch 1, this isn't a bug introduced by this patch, but does
pcpu_create_chunk() overflow chunk->populated on SMP configs?

Answer: I am not familiar with the code, but based on my understanding
and the chat with codex, a patch like below could fix the issue. I will
wait for the feedback from percpu-km people about it.


diff --git a/mm/percpu-km.c b/mm/percpu-km.c
--- a/mm/percpu-km.c
+++ b/mm/percpu-km.c
@@ -74,8 +74,13 @@ static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
 	chunk->data = pages;
 	chunk->base_addr = page_address(pages);
 
+	/*
+	 * nr_pages covers the physical backing for all units.  The populated
+	 * bitmap and pcpu_nr_populated accounting are per-unit, so only mark
+	 * the logical chunk page range populated.
+	 */
 	spin_lock_irqsave(&pcpu_lock, flags);
-	pcpu_chunk_populated(chunk, 0, nr_pages);
+	pcpu_chunk_populated(chunk, 0, chunk->nr_pages);
 	spin_unlock_irqrestore(&pcpu_lock, flags);
 
 	pcpu_stats_chunk_alloc();


Q2: To Patch 5, does replacing the explicit zeroing with a warning leave
the private field uninitialized on production kernels?

Answer: there are a lot of ifs in the question. It starts from one could
allocate a non-compound high-order page and free it without clearing
tail_page->private. This assumption is wrong, since Patch 4 will catch
such code. So there is no issue.


-- 
Best Regards,
Yan, Zi