[PATCH v1 00/11] Zero page->private when freeing pages

[PATCH v1 00/11] Zero page->private when freeing pages

[Zi Yan]

Hi all,

Based on a recent discussion with David Hildenbrand on page->private
is not zero when a page is freed[1], this patchset is trying to fix all
users do not zero ->private when freeing a page and add checks to make
sure all freed pages have ->private set to zero. For compound pages,
both head page and tail pages need to have ->private set to zero.

People are only cc'd on the cover letter and related patches.
Mailing lists get all patches.

Patch 1 to 9: fix all users do not zero ->private upon freeing pages.
I only tested part of them, so would like to get reviews to make sure I
did the right thing.

Patch 10    : restores page->private check in folio split code, since
the code was removed in a prior commit without a proper reason.

Patch 11    : adds checks in page freeing path, __free_pages_prepare(),
to make sure freed pages have zeroed ->prviate.

Any comment or suggestion is welcome.

Thanks.


Link: https://lore.kernel.org/all/91F2E741-5473-4D34-ADA1-C9E6EDCBF5E0@nvidia.com/ [1]


# MM - THP
Cc: David Hildenbrand <david@kernel.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Nico Pache <npache@redhat.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Barry Song <baohua@kernel.org>
Cc: Lance Yang <lance.yang@linux.dev>

# MM - page allocator
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Brendan Jackman <jackmanb@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>

# relay
Cc: Jason Xing <kernelxing@tencent.com>
Cc: Yushan Zhou <katrinzhou@tencent.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>

# MM - slub
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Christoph Lameter <cl@gentwo.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Harry Yoo <harry.yoo@oracle.com>

# DRM TTM
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>

# Block
Cc: Jens Axboe <axboe@kernel.dk>

# watch queue
Cc: Christian Brauner <brauner@kernel.org>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Eric Sandeen <sandeen@redhat.com>

# binder
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Arve Hjønnevåg" <arve@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Carlos Llamas <cmllamas@google.com>
Cc: Alice Ryhl <aliceryhl@google.com>

# null_blk
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>

# percpu
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@gentwo.org>

# erofs
Cc: Gao Xiang <xiang@kernel.org>
Cc: Yue Hu <zbestahu@gmail.com>
Cc: Jeffle Xu <jefflexu@linux.alibaba.com>
Cc: Sandeep Dhavale <dhavale@google.com>
Cc: Hongbo Li <lihongbo22@huawei.com>
Cc: Chunhai Guo <guochunhai@vivo.com>

# lists
Cc: linux-erofs@lists.ozlabs.org
Cc: linux-block@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org

Zi Yan (11):
  relay: zero page->private when freeing pages
  mm/slub: zero page->private when freeing pages
  drm/ttm: zero page->private when freeing pages
  blk-mq: zero page->private when freeing pages
  watch_queue: zero page->private when freeing pages
  binder: zero page->private when freeing pages
  null_blk: zero page->private when freeing pages
  percpu: zero page->private when freeing pages
  erofs: zero page->private when freeing pages
  mm/huge_memory: add page->private check back in
    __split_folio_to_order()
  mm/page_alloc: check page->private upon page free

 block/blk-mq-tag.c             |  6 +++++-
 drivers/android/binder_alloc.c |  1 +
 drivers/block/null_blk/main.c  |  1 +
 drivers/gpu/drm/ttm/ttm_pool.c |  1 +
 fs/erofs/zutil.c               |  1 +
 kernel/relay.c                 |  8 ++++++--
 kernel/watch_queue.c           |  8 ++++++--
 mm/huge_memory.c               | 10 ++++++++++
 mm/page_alloc.c                |  3 ++-
 mm/percpu-vm.c                 |  4 +++-
 mm/slub.c                      |  1 +
 11 files changed, 37 insertions(+), 7 deletions(-)

-- 
2.51.0

[PATCH v1 01/11] relay: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming page->private checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Jason Xing <kernelxing@tencent.com>
Cc: Yushan Zhou <katrinzhou@tencent.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
---
 kernel/relay.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/relay.c b/kernel/relay.c
index 5c665b729132..d16f9966817f 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -131,8 +131,10 @@ static void *relay_alloc_buf(struct rchan_buf *buf, size_t *size)
 	return mem;
 
 depopulate:
-	for (j = 0; j < i; j++)
+	for (j = 0; j < i; j++) {
+		set_page_private(buf->page_array[i], 0);
 		__free_page(buf->page_array[j]);
+	}
 	relay_free_page_array(buf->page_array);
 	return NULL;
 }
@@ -196,8 +198,10 @@ static void relay_destroy_buf(struct rchan_buf *buf)
 
 	if (likely(buf->start)) {
 		vunmap(buf->start);
-		for (i = 0; i < buf->page_count; i++)
+		for (i = 0; i < buf->page_count; i++) {
+			set_page_private(buf->page_array[i], 0);
 			__free_page(buf->page_array[i]);
+		}
 		relay_free_page_array(buf->page_array);
 	}
 	*per_cpu_ptr(chan->buf, buf->cpu) = NULL;
-- 
2.51.0

[PATCH v1 02/11] mm/slub: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Christoph Lameter <cl@gentwo.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Harry Yoo <harry.yoo@oracle.com>
Cc: linux-mm@kvack.org
---
 mm/slub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/slub.c b/mm/slub.c
index 865bc050f654..012c71e7b488 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3511,6 +3511,7 @@ static void __free_slab(struct kmem_cache *s, struct slab *slab, bool allow_spin
 
 	__slab_clear_pfmemalloc(slab);
 	page->mapping = NULL;
+	set_page_private(page, 0);
 	__ClearPageSlab(page);
 	mm_account_reclaimed_pages(pages);
 	unaccount_slab(slab, order, s, allow_spin);
-- 
2.51.0

[PATCH v1 03/11] drm/ttm: zero page->private when freeing pages

[Zi Yan]

This prepares upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/ttm/ttm_pool.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 217e45958099..a85cf1582dc8 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -210,6 +210,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching,
 #endif
 
 	if (!pool || !ttm_pool_uses_dma_alloc(pool)) {
+		set_page_private(p, 0);
 		__free_pages(p, order);
 		return;
 	}
-- 
2.51.0

[PATCH v1 04/11] blk-mq: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
---
 block/blk-mq-tag.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 33946cdb5716..2d4bdf8df51d 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -589,14 +589,18 @@ static void blk_mq_free_tags_callback(struct rcu_head *head)
 	struct page *page;
 
 	while (!list_empty(&tags->page_list)) {
+		int order;
+
 		page = list_first_entry(&tags->page_list, struct page, lru);
 		list_del_init(&page->lru);
+		order = page->private;
 		/*
 		 * Remove kmemleak object previously allocated in
 		 * blk_mq_alloc_rqs().
 		 */
 		kmemleak_free(page_address(page));
-		__free_pages(page, page->private);
+		set_page_private(page, 0);
+		__free_pages(page, order);
 	}
 	kfree(tags);
 }
-- 
2.51.0

[PATCH v1 05/11] watch_queue: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Eric Sandeen <sandeen@redhat.com>
---
 kernel/watch_queue.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/watch_queue.c b/kernel/watch_queue.c
index 52f89f1137da..8f887eafd438 100644
--- a/kernel/watch_queue.c
+++ b/kernel/watch_queue.c
@@ -301,8 +301,10 @@ long watch_queue_set_size(struct pipe_inode_info *pipe, unsigned int nr_notes)
 	return 0;
 
 error_p:
-	while (--i >= 0)
+	while (--i >= 0) {
+		set_page_private(pages[i], 0);
 		__free_page(pages[i]);
+	}
 	kfree(pages);
 error:
 	(void) account_pipe_buffers(pipe->user, nr_pages, pipe->nr_accounted);
@@ -398,8 +400,10 @@ static void __put_watch_queue(struct kref *kref)
 	struct watch_filter *wfilter;
 	int i;
 
-	for (i = 0; i < wqueue->nr_pages; i++)
+	for (i = 0; i < wqueue->nr_pages; i++) {
+		set_page_private(wqueue->notes[i], 0);
 		__free_page(wqueue->notes[i]);
+	}
 	kfree(wqueue->notes);
 	bitmap_free(wqueue->notes_bitmap);
 
-- 
2.51.0

[PATCH v1 06/11] binder: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Arve Hjønnevåg" <arve@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Carlos Llamas <cmllamas@google.com>
Cc: Alice Ryhl <aliceryhl@google.com>
---
 drivers/android/binder_alloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 67a068c075c0..5c960513c7bc 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -306,6 +306,7 @@ static struct page *binder_page_alloc(struct binder_alloc *alloc,
 static void binder_free_page(struct page *page)
 {
 	kfree((struct binder_shrinker_mdata *)page_private(page));
+	set_page_private(page, 0);
 	__free_page(page);
 }
 
-- 
2.51.0

[PATCH v1 07/11] null_blk: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: linux-block@vger.kernel.org
---
 drivers/block/null_blk/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
index 740a8ac42075..86ea2644080f 100644
--- a/drivers/block/null_blk/main.c
+++ b/drivers/block/null_blk/main.c
@@ -886,6 +886,7 @@ static void null_free_page(struct nullb_page *t_page)
 	__set_bit(NULLB_PAGE_FREE, t_page->bitmap);
 	if (test_bit(NULLB_PAGE_LOCK, t_page->bitmap))
 		return;
+	set_page_private(t_page->page, 0);
 	__free_page(t_page->page);
 	kfree(t_page);
 }
-- 
2.51.0

[PATCH v1 08/11] percpu: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@gentwo.org>
Cc: linux-mm@kvack.org
---
 mm/percpu-vm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
index 4f5937090590..edc8f4448a8e 100644
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -61,8 +61,10 @@ static void pcpu_free_pages(struct pcpu_chunk *chunk,
 		for (i = page_start; i < page_end; i++) {
 			struct page *page = pages[pcpu_page_idx(cpu, i)];
 
-			if (page)
+			if (page) {
+				set_page_private(page, 0);
 				__free_page(page);
+			}
 		}
 	}
 }
-- 
2.51.0

[PATCH v1 09/11] erofs: zero page->private when freeing pages

[Zi Yan]

This prepares for upcoming checks in page freeing path.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Gao Xiang <xiang@kernel.org>
Cc: Yue Hu <zbestahu@gmail.com>
Cc: Jeffle Xu <jefflexu@linux.alibaba.com>
Cc: Sandeep Dhavale <dhavale@google.com>
Cc: Hongbo Li <lihongbo22@huawei.com>
Cc: Chunhai Guo <guochunhai@vivo.com>
Cc: linux-erofs@lists.ozlabs.org
---
 fs/erofs/zutil.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/erofs/zutil.c b/fs/erofs/zutil.c
index 55ff2ab5128e..94310b70e6af 100644
--- a/fs/erofs/zutil.c
+++ b/fs/erofs/zutil.c
@@ -210,6 +210,7 @@ void erofs_release_pages(struct page **pagepool)
 			}
 			spin_unlock(&z_erofs_rsvbuf->lock);
 		}
+		set_page_private(page, 0);
 		put_page(page);
 	}
 }
-- 
2.51.0

[PATCH v1 10/11] mm/huge_memory: add page->private check back in __split_folio_to_order()

[Zi Yan]

page->private should not be set in tail pages. Commit 4265d67e405a
("mm/migrate_device: add THP splitting during migration") removed it
without a proper reason. Add it back.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Nico Pache <npache@redhat.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Barry Song <baohua@kernel.org>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: linux-mm@kvack.org
---
 mm/huge_memory.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 27316d741927..6b57d219fc97 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3548,6 +3548,16 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
 		new_folio->mapping = folio->mapping;
 		new_folio->index = folio->index + i;
 
+		/*
+		 * page->private should not be set in tail pages. Fix up and warn once
+		 * if private is unexpectedly set. Do it before swap.val assignment
+		 * since private overlaps with swap.val.
+		 */
+		if (unlikely(new_folio->private)) {
+			VM_WARN_ON_ONCE_PAGE(true, new_head);
+			new_folio->private = NULL;
+		}
+
 		if (folio_test_swapcache(folio))
 			new_folio->swap.val = folio->swap.val + i;
 
-- 
2.51.0

[PATCH v1 11/11] mm/page_alloc: check page->private upon page free

[Zi Yan]

Any user is supposed to zero their allocated page->private at free time,
including both head and tail pages if the freed page is compound. Add
VM_WARN_ON_ONCE to check page->private.

Whoever encountering warnings from this commit needs to fix code that
does not zero ->private when freeing a page/folio.

Signed-off-by: Zi Yan <ziy@nvidia.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Brendan Jackman <jackmanb@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
---
 mm/page_alloc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d88c8c67ac0b..d8b7f36e9364 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1410,6 +1410,7 @@ __always_inline bool __free_pages_prepare(struct page *page,
 				}
 			}
 			(page + i)->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
+			VM_WARN_ON_ONCE((page + i)->private);
 		}
 	}
 	if (folio_test_anon(folio)) {
@@ -1429,7 +1430,7 @@ __always_inline bool __free_pages_prepare(struct page *page,
 
 	page_cpupid_reset_last(page);
 	page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
-	page->private = 0;
+	VM_WARN_ON_ONCE(page->private);
 	reset_page_owner(page, order);
 	page_table_check_free(page, order);
 	pgalloc_tag_sub(page, 1 << order);
-- 
2.51.0

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[Matthew Wilcox]

On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote:
> Based on a recent discussion with David Hildenbrand on page->private
> is not zero when a page is freed[1], this patchset is trying to fix all
> users do not zero ->private when freeing a page and add checks to make
> sure all freed pages have ->private set to zero. For compound pages,
> both head page and tail pages need to have ->private set to zero.

Sorry, I didn't notice this conversation.  It seems entirely unnecessary
to me to zero out page->private before freeing.

I'm a bit confused that ac1ea219590c was needed too; I thought we
cleared page->private in the allocation path, and I don't see why
it needs to be cleared in the freeing path.  split_page() should be
clearing page->private.

Can we discuss this at the THP Cabal meeting on Wednesday?  I don't
think that introducing this new rule that page->private must be cleared
by the users is a good idea.

[syzbot ci] Re: Zero page->private when freeing pages

[syzbot ci]

syzbot ci has tested the following series

[v1] Zero page->private when freeing pages
https://lore.kernel.org/all/20260223032641.1859381-1-ziy@nvidia.com
* [PATCH v1 01/11] relay: zero page->private when freeing pages
* [PATCH v1 02/11] mm/slub: zero page->private when freeing pages
* [PATCH v1 03/11] drm/ttm: zero page->private when freeing pages
* [PATCH v1 04/11] blk-mq: zero page->private when freeing pages
* [PATCH v1 05/11] watch_queue: zero page->private when freeing pages
* [PATCH v1 06/11] binder: zero page->private when freeing pages
* [PATCH v1 07/11] null_blk: zero page->private when freeing pages
* [PATCH v1 08/11] percpu: zero page->private when freeing pages
* [PATCH v1 09/11] erofs: zero page->private when freeing pages
* [PATCH v1 10/11] mm/huge_memory: add page->private check back in __split_folio_to_order()
* [PATCH v1 11/11] mm/page_alloc: check page->private upon page free

and found the following issue:
WARNING in __free_frozen_pages

Full report is available here:
https://ci.syzbot.org/series/10f470ac-46ac-4e38-902d-dc86ae743494

***

WARNING in __free_frozen_pages

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      a6fdc327de4678e54b5122441c970371014117b0
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/0586347c-8ef1-427f-8a9c-7f6c08b616a9/config

Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: HIDP socket layer initialized
NET: Registered PF_RXRPC protocol family
Key type rxrpc registered
Key type rxrpc_s registered
NET: Registered PF_KCM protocol family
lec:lane_module_init: lec.c: initialized
mpoa:atm_mpoa_init: mpc.c: initialized
l2tp_core: L2TP core driver, V2.0
l2tp_ppp: PPPoL2TP kernel driver, V2.0
l2tp_ip: L2TP IP encapsulation support (L2TPv3)
l2tp_netlink: L2TP netlink interface
l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
NET: Registered PF_PHONET protocol family
8021q: 802.1Q VLAN Support v1.8
sctp: Hash tables configured (bind 32/56)
NET: Registered PF_RDS protocol family
Registered RDS/infiniband transport
Registered RDS/tcp transport
tipc: Activated (version 2.0.0)
NET: Registered PF_TIPC protocol family
tipc: Started in single node mode
smc: adding smcd device lo without pnetid
NET: Registered PF_SMC protocol family
9pnet: Installing 9P2000 support
NET: Registered PF_CAIF protocol family
NET: Registered PF_IEEE802154 protocol family
Key type dns_resolver registered
Key type ceph registered
libceph: loaded (mon/osd proto 15/24)
batman_adv: B.A.T.M.A.N. advanced 2025.5 (compatibility version 15) loaded
openvswitch: Open vSwitch switching datapath
NET: Registered PF_VSOCK protocol family
mpls_gso: MPLS GSO support
IPI shorthand broadcast: enabled
sched_clock: Marking stable (19970046340, 93374727)->(20073238384, -9817317)
registered taskstats version 1
Loading compiled-in X.509 certificates
Loaded X.509 cert 'Build time autogenerated kernel key: 98092a222e11368da223b039d625e21c3e2e069c'
zswap: loaded using pool 842
Demotion targets for Node 0: null
Demotion targets for Node 1: null
debug_vm_pgtable: [debug_vm_pgtable         ]: Validating architecture page table helpers
------------[ cut here ]------------
page->private
WARNING: mm/page_alloc.c:1433 at __free_frozen_pages+0x78e/0xe10, CPU#0: swapper/0/1
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:__free_frozen_pages+0x78e/0xe10
Code: 5f 5d e9 05 1e 00 00 48 b8 00 00 00 00 00 fc ff df 0f b6 44 05 00 84 c0 0f 85 d7 02 00 00 c7 03 ff ff ff ff e9 22 fc ff ff 90 <0f> 0b 90 e9 8d fc ff ff bd 01 00 00 00 83 f8 05 0f 85 bb fe ff ff
RSP: 0000:ffffc900000676e0 EFLAGS: 00010282
RAX: 1ffffd4000bad935 RBX: ffffea0005d6c9a8 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffea0005d6c9b4
RBP: ffffea0005d6c9b8 R08: ffffea0005d6c9b7 R09: 1ffffd4000bad936
R10: dffffc0000000000 R11: fffff94000bad937 R12: ffffea0005d6c980
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88818de64000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88823ffff000 CR3: 000000000e54c000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 destroy_args+0x15d/0x570
 debug_vm_pgtable+0x3f8/0x410
 do_one_initcall+0x250/0x8d0
 do_initcall_level+0x104/0x190
 do_initcalls+0x59/0xa0
 kernel_init_freeable+0x2a6/0x3e0
 kernel_init+0x1d/0x1d0
 ret_from_fork+0x51e/0xb90
 ret_from_fork_asm+0x1a/0x30
 </TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[David Hildenbrand (Arm)]

On 2/23/26 05:28, Matthew Wilcox wrote:
> On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote:
>> Based on a recent discussion with David Hildenbrand on page->private
>> is not zero when a page is freed[1], this patchset is trying to fix all
>> users do not zero ->private when freeing a page and add checks to make
>> sure all freed pages have ->private set to zero. For compound pages,
>> both head page and tail pages need to have ->private set to zero.
> 
> Sorry, I didn't notice this conversation.  It seems entirely unnecessary
> to me to zero out page->private before freeing.
> 
> I'm a bit confused that ac1ea219590c was needed too; I thought we
> cleared page->private in the allocation path, and I don't see why
> it needs to be cleared in the freeing path.  split_page() should be
> clearing page->private.

See discussion at 
https://lore.kernel.org/linux-mm/cbc3b5b3-09b5-4e3c-99f0-a1f67582afff@kernel.org/

> 
> Can we discuss this at the THP Cabal meeting on Wednesday?  I don't
> think that introducing this new rule that page->private must be cleared
> by the users is a good idea.

The benefit is that only the users that really use page->private will 
also zero it out.

This implies that all pages that enter+leave the page allocator will 
have page->private initialized and we can also likely do:

diff --git a/mm/internal.h b/mm/internal.h
index 9e0577413087..4ecdae78e0d2 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -724,7 +724,6 @@ static inline void prep_compound_tail(struct page 
*head, int tail_idx)

         p->mapping = TAIL_MAPPING;
         set_compound_head(p, head);
-       set_page_private(p, 0);
  }

  extern void prep_compound_page(struct page *page, unsigned int order);


Which is rather nice.

-- 
Cheers,

David

Re: [PATCH v1 03/11] drm/ttm: zero page->private when freeing pages

[Christian König]

On 2/23/26 04:26, Zi Yan wrote:
> This prepares upcoming checks in page freeing path.
> 
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Huang Rui <ray.huang@amd.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org

Acked-by: Christian König <christian.koenig@amd.com>

Question (which was potentially already discussed) why isn't __free_pages() doing that?

Regards,
Christian.

> ---
>  drivers/gpu/drm/ttm/ttm_pool.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index 217e45958099..a85cf1582dc8 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -210,6 +210,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching,
>  #endif
>  
>  	if (!pool || !ttm_pool_uses_dma_alloc(pool)) {
> +		set_page_private(p, 0);
>  		__free_pages(p, order);
>  		return;
>  	}

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[Zi Yan]

On 23 Feb 2026, at 8:46, Christoph Hellwig wrote:

> On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote:
>> Hi all,
>>
>> Based on a recent discussion with David Hildenbrand on page->private
>> is not zero when a page is freed[1], this patchset is trying to fix all
>> users do not zero ->private when freeing a page and add checks to make
>> sure all freed pages have ->private set to zero. For compound pages,
>> both head page and tail pages need to have ->private set to zero.
>
> Requiring the user to clear a field before freeing is just a way to
> awkward interface.  Don't do that.

Page allocator hands the user a zero ->private. I think it is reasonable
to require the user to return a zero ->private. Restoring things back
to their original states is a common standard, isn't it? And most of
users do that.

Do you have any example that shows doing such a thing is difficult,
if not impossible?


--
Best Regards,
Yan, Zi

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[Christian König]

On 2/23/26 14:46, Christoph Hellwig wrote:
> On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote:
>> Hi all,
>>
>> Based on a recent discussion with David Hildenbrand on page->private
>> is not zero when a page is freed[1], this patchset is trying to fix all
>> users do not zero ->private when freeing a page and add checks to make
>> sure all freed pages have ->private set to zero. For compound pages,
>> both head page and tail pages need to have ->private set to zero.
> 
> Requiring the user to clear a field before freeing is just a way to
> awkward interface.  Don't do that.

Completely agree. This is just asking for trouble.

The cache line(s) backing this struct page are most likely accessed anyway on free/alloc. So I don't see much extra overhead.

Regards,
Christian.

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[Zi Yan]

On 23 Feb 2026, at 9:03, Christoph Hellwig wrote:

> On Mon, Feb 23, 2026 at 09:00:57AM -0500, Zi Yan wrote:
>>> awkward interface.  Don't do that.
>>
>> Page allocator hands the user a zero ->private. I think it is reasonable
>> to require the user to return a zero ->private. Restoring things back
>> to their original states is a common standard, isn't it? And most of
>> users do that.
>
> No other relevant interface requires private data pointers, as that would
> be silly and cause tons of bugs.

filesystems use ->private and zero it before freeing a page. Can you provide a concrete
example showing that requirement will cause bugs or make other functions hard to
implement? With good examples, we can document them and make sure MM handle them
properly (i.e., zeroing ->private for them).

--
Best Regards,
Yan, Zi

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[David Hildenbrand (Arm)]

On 2/23/26 15:06, Christian König wrote:
> On 2/23/26 14:46, Christoph Hellwig wrote:
>> On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote:
>>> Hi all,
>>>
>>> Based on a recent discussion with David Hildenbrand on page->private
>>> is not zero when a page is freed[1], this patchset is trying to fix all
>>> users do not zero ->private when freeing a page and add checks to make
>>> sure all freed pages have ->private set to zero. For compound pages,
>>> both head page and tail pages need to have ->private set to zero.
>>
>> Requiring the user to clear a field before freeing is just a way to
>> awkward interface.  Don't do that.
> 
> Completely agree. This is just asking for trouble.
> 
> The cache line(s) backing this struct page are most likely accessed anyway on free/alloc. So I don't see much extra overhead.

I think the question is more around handling non-head pages when freeing 
larger orders. But maybe the overhead of zeroing page->private it there 
as well in __free_pages_prepare() is tolerable.

I'll note, though, that we already require page->mapping and 
page->memcg_data of pages to be zeroed by the caller, so it's not 
completely crazy. (see page_expected_state)

-- 
Cheers,

David

Re: [PATCH v1 01/11] relay: zero page->private when freeing pages

[Usama Arif]

On Sun, 22 Feb 2026 22:26:31 -0500 Zi Yan <ziy@nvidia.com> wrote:

> This prepares for upcoming page->private checks in page freeing path.
> 
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Cc: Jason Xing <kernelxing@tencent.com>
> Cc: Yushan Zhou <katrinzhou@tencent.com>
> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
> ---
>  kernel/relay.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 5c665b729132..d16f9966817f 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -131,8 +131,10 @@ static void *relay_alloc_buf(struct rchan_buf *buf, size_t *size)
>  	return mem;
>  
>  depopulate:
> -	for (j = 0; j < i; j++)
> +	for (j = 0; j < i; j++) {
> +		set_page_private(buf->page_array[i], 0);

Hi Zi,

Should the index into page_array be j and not i over here?

>  		__free_page(buf->page_array[j]);
> +	}
>  	relay_free_page_array(buf->page_array);
>  	return NULL;
>  }
> @@ -196,8 +198,10 @@ static void relay_destroy_buf(struct rchan_buf *buf)
>  
>  	if (likely(buf->start)) {
>  		vunmap(buf->start);
> -		for (i = 0; i < buf->page_count; i++)
> +		for (i = 0; i < buf->page_count; i++) {
> +			set_page_private(buf->page_array[i], 0);
>  			__free_page(buf->page_array[i]);
> +		}
>  		relay_free_page_array(buf->page_array);
>  	}
>  	*per_cpu_ptr(chan->buf, buf->cpu) = NULL;
> -- 
> 2.51.0
> 
> 

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[Christian König]

On 2/23/26 15:14, David Hildenbrand (Arm) wrote:
> On 2/23/26 15:06, Christian König wrote:
>> On 2/23/26 14:46, Christoph Hellwig wrote:
>>> On Sun, Feb 22, 2026 at 10:26:30PM -0500, Zi Yan wrote:
>>>> Hi all,
>>>>
>>>> Based on a recent discussion with David Hildenbrand on page->private
>>>> is not zero when a page is freed[1], this patchset is trying to fix all
>>>> users do not zero ->private when freeing a page and add checks to make
>>>> sure all freed pages have ->private set to zero. For compound pages,
>>>> both head page and tail pages need to have ->private set to zero.
>>>
>>> Requiring the user to clear a field before freeing is just a way to
>>> awkward interface.  Don't do that.
>>
>> Completely agree. This is just asking for trouble.
>>
>> The cache line(s) backing this struct page are most likely accessed anyway on free/alloc. So I don't see much extra overhead.
> 
> I think the question is more around handling non-head pages when freeing larger orders. But maybe the overhead of zeroing page->private it there as well in __free_pages_prepare() is tolerable.

Good point, sounds like that is a bit more than I thought it would be.

> I'll note, though, that we already require page->mapping and page->memcg_data of pages to be zeroed by the caller, so it's not completely crazy. (see page_expected_state)

Well that's not defensive at all, basically everybody which forgets to do that can cause hard to debug trouble. Maybe that practice should be reconsidered.

Regards,
Christian.

Re: [PATCH v1 00/11] Zero page->private when freeing pages

[David Hildenbrand (Arm)]

On 2/23/26 16:22, Christian König wrote:
> On 2/23/26 15:14, David Hildenbrand (Arm) wrote:
>> On 2/23/26 15:06, Christian König wrote:
>>>
>>> Completely agree. This is just asking for trouble.
>>>
>>> The cache line(s) backing this struct page are most likely accessed anyway on free/alloc. So I don't see much extra overhead.
>>
>> I think the question is more around handling non-head pages when freeing larger orders. But maybe the overhead of zeroing page->private it there as well in __free_pages_prepare() is tolerable.
> 
> Good point, sounds like that is a bit more than I thought it would be.

Right. We already iterate over all "tail" pages in 
__free_pages_prepare() to clear page flags

	(page + i)->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;

Maybe zeroing page->private there is not too bad.

> 
>> I'll note, though, that we already require page->mapping and page->memcg_data of pages to be zeroed by the caller, so it's not completely crazy. (see page_expected_state)
> 
> Well that's not defensive at all, basically everybody which forgets to do that can cause hard to debug trouble. Maybe that practice should be reconsidered.

Right, we do have check_pages= to activate the page_expected_state() 
checks, where we will detect such problems.

(including the mapcount being -1 etc.)

-- 
Cheers,

David

Claude review: Zero page->private when freeing pages

[Claude Code Review Bot]

Overall Series Review

Subject: Zero page->private when freeing pages
Author: Zi Yan <ziy@nvidia.com>
Patches: 22
Reviewed: 2026-02-24T10:52:52.290001

---

This series from Zi Yan aims to enforce the invariant that `page->private` must be zero when a page is returned to the page allocator. Patches 1-9 fix individual subsystems that store data in `page->private` but don't zero it before freeing. Patch 10 restores a check in folio splitting, and patch 11 adds a `VM_WARN_ON_ONCE` in `__free_pages_prepare()` to catch any remaining violators.

The approach is reasonable and comes from a discussion with David Hildenbrand. However, there is a bug in patch 1 (wrong loop variable causing a NULL pointer dereference), and patch 3 (drm/ttm) only handles one of the two freeing paths. Patch 11 removes the existing `page->private = 0` safety net in the page allocator, replacing it with only a warning. This means any missed caller will now silently leak stale private data to the next page consumer, which is a correctness regression compared to the previous defensive clearing.

The series also has a general weakness: the commit messages for patches 1-9 are all nearly identical ("This prepares for upcoming checks in page freeing path.") and don't explain what the subsystem was storing in `page->private` or why it was non-zero. That context would be valuable for reviewers.

---
Generated by Claude Code Patch Reviewer

Claude review: relay: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

There is a bug in the depopulate error path. The patch uses `i` when it should use `j`:

> depopulate:
> -	for (j = 0; j < i; j++)
> +	for (j = 0; j < i; j++) {
> +		set_page_private(buf->page_array[i], 0);
> 		__free_page(buf->page_array[j]);
> +	}

The `set_page_private` call uses `buf->page_array[i]`, but at the `depopulate` label, `i` is the index where `alloc_page()` failed. That means `buf->page_array[i]` is NULL (the allocation returned NULL). This will cause a NULL pointer dereference in `set_page_private`. The correct index is `j`, matching the `__free_page` call on the next line.

The second hunk in `relay_destroy_buf` correctly uses `i` for both calls since the same loop variable is used throughout:

> -		for (i = 0; i < buf->page_count; i++)
> +		for (i = 0; i < buf->page_count; i++) {
> +			set_page_private(buf->page_array[i], 0);
> 			__free_page(buf->page_array[i]);
> +		}

This part is correct.

---
Generated by Claude Code Patch Reviewer

Claude review: mm/slub: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> +	set_page_private(page, 0);
>  	__ClearPageSlab(page);

No issues. The placement before `__ClearPageSlab` and the existing `page->mapping = NULL` is appropriate.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/ttm: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> 	if (!pool || !ttm_pool_uses_dma_alloc(pool)) {
> +		set_page_private(p, 0);
> 		__free_pages(p, order);
> 		return;
> 	}

This only handles the non-DMA allocation path. Looking at `ttm_pool_free_page`, the DMA allocation path (the else branch) also stores a `struct ttm_pool_dma *` pointer in `p->private`:

```c
dma = (void *)p->private;
vaddr = (void *)(dma->vaddr & PAGE_MASK);
dma_free_attrs(pool->dev, ..., vaddr, dma->addr, attr);
kfree(dma);
```

After `dma_free_attrs`, the underlying pages are freed with `page->private` still pointing to the (now kfree'd) DMA metadata. If those pages eventually reach `__free_pages_prepare` (which many DMA implementations will do), the check added by patch 11 would fire. Should `set_page_private(p, 0)` be added before the `dma_free_attrs` call in the DMA path as well?

Christian Koenig acked the patch but also asked why `__free_pages()` doesn't just do the zeroing itself -- which is a reasonable question given the approach taken in patch 11.

---
Generated by Claude Code Patch Reviewer

Claude review: blk-mq: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> +		int order;
> +
>  		page = list_first_entry(&tags->page_list, struct page, lru);
>  		list_del_init(&page->lru);
> +		order = page->private;
> ...
> -		__free_pages(page, page->private);
> +		set_page_private(page, 0);
> +		__free_pages(page, order);

This is correct. The order is saved to a local variable before zeroing private, then used in `__free_pages`. Clean approach.

---
Generated by Claude Code Patch Reviewer

Claude review: watch_queue: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

No issues. Both the error path and the normal teardown path correctly zero private before freeing the page using the correct loop index.

---
Generated by Claude Code Patch Reviewer

Claude review: binder: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> 	kfree((struct binder_shrinker_mdata *)page_private(page));
> +	set_page_private(page, 0);
> 	__free_page(page);

No issues. The private (which holds a pointer to binder metadata) is freed via `kfree`, then zeroed, then the page is freed.

---
Generated by Claude Code Patch Reviewer

Claude review: null_blk: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> +	set_page_private(t_page->page, 0);
> 	__free_page(t_page->page);
> 	kfree(t_page);

No issues.

---
Generated by Claude Code Patch Reviewer

Claude review: percpu: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> -			if (page)
> +			if (page) {
> +				set_page_private(page, 0);
> 				__free_page(page);
> +			}

No issues.

---
Generated by Claude Code Patch Reviewer

Claude review: erofs: zero page->private when freeing pages

[Claude Code Review Bot]

Patch Review

> +		set_page_private(page, 0);
> 		put_page(page);

No issues. The `page->private` is used as a linked-list next pointer in erofs page pools. Zeroing before `put_page` is correct.

---
Generated by Claude Code Patch Reviewer

Claude review: mm/huge_memory: add page->private check back in __split_folio_to_order()

[Claude Code Review Bot]

Patch Review

> +		/*
> +		 * page->private should not be set in tail pages. Fix up and warn once
> +		 * if private is unexpectedly set. Do it before swap.val assignment
> +		 * since private overlaps with swap.val.
> +		 */
> +		if (unlikely(new_folio->private)) {
> +			VM_WARN_ON_ONCE_PAGE(true, new_head);
> +			new_folio->private = NULL;
> +		}
> +
>  		if (folio_test_swapcache(folio))
>  			new_folio->swap.val = folio->swap.val + i;

The comment says "private overlaps with swap.val" and the check is placed before the swap.val assignment. If this is a swapcache folio, the swap.val assignment will overwrite private anyway. But for non-swapcache folios, if a tail page had unexpected private data, this catches and clears it. The logic is sound.

The commit message says commit 4265d67e405a removed this check "without a proper reason." It would be helpful to explain what situation produces non-zero private in tail pages, rather than just asserting the prior commit was wrong.

---
Generated by Claude Code Patch Reviewer

Claude review: mm/page_alloc: check page->private upon page free

[Claude Code Review Bot]

Patch Review

> -	page->private = 0;
> +	VM_WARN_ON_ONCE(page->private);

This removes the safety-net zeroing of `page->private` for the head page and replaces it with only a warning. The loop body for sub-pages also only adds a warning:

> 			(page + i)->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
> +			VM_WARN_ON_ONCE((page + i)->private);

Two concerns:

First, `VM_WARN_ON_ONCE` only fires in debug kernels (when `CONFIG_DEBUG_VM` is set). In production kernels without this config, the `VM_WARN_ON_ONCE` compiles to nothing, meaning the old `page->private = 0` is simply deleted with no replacement. Any subsystem missed by patches 1-9 would silently leave stale data in private, potentially affecting the next page consumer. This is a correctness regression compared to the previous unconditional clearing.

Second, this is `WARN_ON_ONCE`, so only the first violation will be reported. If there are multiple subsystems that still need fixing, only one will be visible per boot.

The cover letter acknowledges the author "only tested part of" the subsystem fixes. Given that, removing the safety net in `__free_pages_prepare` seems premature. Would it be safer to keep the `page->private = 0` and add a `VM_WARN_ON_ONCE` check *before* the zeroing? That would catch violators while still maintaining the safety net:

```c
VM_WARN_ON_ONCE(page->private);
page->private = 0;
```

---
Generated by Claude Code Patch Reviewer