From: sashiko-bot@kernel.org
To: "Qi Zheng" <qi.zheng@linux.dev>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Kairui Song" <kasong@tencent.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Gregory Price" <gourry@gourry.net>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"David Hildenbrand" <david@kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Dev Jain" <dev.jain@arm.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Liam R. Howlett" <liam@infradead.org>,
"Michal Hocko" <mhocko@suse.com>,
"Lance Yang" <lance.yang@linux.dev>,
"Ying Huang" <ying.huang@linux.alibaba.com>,
"Zi Yan" <ziy@nvidia.com>, "Muchun Song" <muchun.song@linux.dev>,
"Mike Rapoport" <rppt@kernel.org>,
"Barry Song" <baohua@kernel.org>,
"Nico Pache" <nico.pache@linux.dev>,
"Usama Arif" <usama.arif@linux.dev>
Cc: "Steven Rostedt" <rostedt@goodmis.org>, "Jan Kara" <jack@suse.cz>,
"Baoquan He" <baoquan.he@linux.dev>,
linux-mm@kvack.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Masami Hiramatsu" <mhiramat@kernel.org>,
linux-fsdevel@vger.kernel.org,
"Pratyush Yadav" <pratyush@kernel.org>,
"Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Dave Young" <ruirui.yang@linux.dev>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 16/16] mm/page-flags: remove PG_private
Date: Mon, 14 Sep 2026 02:47:59 +0000 [thread overview]
Message-ID: <20260914024800.087EF1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260913-remove-pg_private-v4-16-848550f7574e@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Silent memory leak of folio private data due to missing check for leaked `folio->private` data when a head page is freed.
--
commit ebe4dd474a496c46897e3f790e03a43cc0508eaf
Author: Zi Yan <ziy@nvidia.com>
mm/page-flags: remove PG_private
folio->private != NULL indicates a folio carries private data, replacing
PG_private. All PG_private users are converted. Remove PG_private and
reserve the space as PG_folio for future use. Unused PG_private functions
are removed too.
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 08988877331ba..10f4ad075ea48 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
[ ... ]
> @@ -105,7 +101,7 @@ enum pageflags {
> PG_owner_2, /* Owner use. If pagecache, fs may use */
> PG_arch_1,
> PG_reserved,
> - PG_private, /* If pagecache, has fs-private data */
> + PG_folio, /* Do not use: reserved for folio identification */
[Severity: High]
With the removal of PG_private, does the free path for head pages fail to
validate whether private data is leaked?
Previously, the memory management subsystem checked for PG_private during page
freeing (via PAGE_FLAGS_CHECK_AT_FREE) to catch filesystem leaks, and issued a
bad_page() warning if it was still set.
While tail pages are explicitly checked for leaked private data in the free
path:
if (tail_page->private) {
bad_page(tail_page, "nonzero private");
...
The head page's private field appears to be unconditionally zeroed without
validation in __free_pages_prepare() in mm/page_alloc.c:
page_cpupid_reset_last(page);
page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
page->private = 0;
reset_page_owner(page, order);
Can this silently mask bugs where filesystems leak private data (like an
un-detached buffer_head)? Should we add a check for page->private != NULL
for head pages before unconditionally zeroing it?
> PG_private_2, /* If pagecache, has fs aux data */
> PG_reclaim, /* To be reclaimed asap */
> PG_swapbacked, /* Page is backed by RAM/swap */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com?part=16
next prev parent reply other threads:[~2026-09-14 2:48 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 2:23 [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Zi Yan
2026-09-14 2:23 ` Zi Yan
2026-09-14 2:23 ` [f2fs-dev] " Zi Yan via Linux-f2fs-devel
2026-09-14 2:23 ` [PATCH v4 01/16] mm/zsmalloc: replace PG_private with pointer comparison Zi Yan
2026-09-14 2:24 ` [PATCH v4 02/16] perf/ring_buffer: stop using PG_private as AUX page high-order marker Zi Yan
2026-09-14 2:36 ` sashiko-bot
2026-09-14 2:24 ` [PATCH v4 03/16] xen/grant-table: stop setting PG_private on pages for grant mapping Zi Yan
2026-09-14 13:15 ` David Hildenbrand (Arm)
2026-09-14 2:24 ` [PATCH v4 04/16] fscrypt: stop setting PG_private on bounce page Zi Yan
2026-09-14 2:24 ` [PATCH v4 05/16] mm/hugetlb: use direct assignment instead of folio_change_private() Zi Yan
2026-09-14 2:58 ` Muchun Song
2026-09-14 13:16 ` David Hildenbrand (Arm)
2026-09-16 1:56 ` Zi Yan
2026-09-16 6:12 ` David Hildenbrand (Arm)
2026-09-18 1:41 ` Zi Yan
2026-09-18 3:13 ` Muchun Song
2026-09-14 2:24 ` [f2fs-dev] [PATCH v4 06/16] f2fs: stop using PG_private Zi Yan via Linux-f2fs-devel
2026-09-14 2:24 ` Zi Yan
2026-09-14 13:17 ` [f2fs-dev] " David Hildenbrand (Arm) via Linux-f2fs-devel
2026-09-14 13:17 ` David Hildenbrand (Arm)
2026-09-14 2:24 ` [f2fs-dev] [PATCH v4 07/16] f2fs: convert the ->private flag helpers to folio-only Zi Yan via Linux-f2fs-devel
2026-09-14 2:24 ` Zi Yan
2026-09-16 2:20 ` [f2fs-dev] " Zi Yan via Linux-f2fs-devel
2026-09-16 2:20 ` Zi Yan
2026-09-14 2:24 ` [PATCH v4 08/16] erofs: mm/pagemap: add readahead_folio_last() to avoid folio->private Zi Yan
2026-09-14 2:24 ` [PATCH v4 09/16] erofs: use folio_attach/detach_private() instead of direct assignment Zi Yan
2026-09-14 13:18 ` David Hildenbrand (Arm)
2026-09-14 2:24 ` [PATCH v4 10/16] mm/page-flags: check page/folio->private instead of PG_private Zi Yan
2026-09-14 13:26 ` David Hildenbrand (Arm)
2026-09-14 14:44 ` Zi Yan
2026-09-14 15:11 ` David Hildenbrand (Arm)
2026-09-14 15:21 ` Zi Yan
2026-09-14 2:24 ` [PATCH v4 11/16] treewide: remove folio_set/clear_private() usage Zi Yan
2026-09-14 2:24 ` [PATCH v4 12/16] ceph: replace PagePrivate() with page_private() Zi Yan
2026-09-14 13:26 ` David Hildenbrand (Arm)
2026-09-14 2:24 ` [PATCH v4 13/16] md/md-bitmap: " Zi Yan
2026-09-14 2:24 ` [PATCH v4 14/16] buffer: replace page_buffer() with page_private() and delete it Zi Yan
2026-09-14 2:24 ` [PATCH v4 15/16] treewide: remove PagePrivate() and PG_private from comments and docs Zi Yan
2026-09-14 2:24 ` Zi Yan
2026-09-14 13:36 ` David Hildenbrand (Arm)
2026-09-14 13:36 ` David Hildenbrand (Arm)
2026-09-14 2:24 ` [PATCH v4 16/16] mm/page-flags: remove PG_private Zi Yan
2026-09-14 2:47 ` sashiko-bot [this message]
2026-09-14 13:37 ` David Hildenbrand (Arm)
2026-09-14 13:38 ` David Hildenbrand (Arm)
2026-09-14 3:39 ` [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Andrew Morton
2026-09-14 3:39 ` Andrew Morton
2026-09-14 3:39 ` [f2fs-dev] " Andrew Morton
2026-09-15 17:16 ` Zi Yan
2026-09-15 17:16 ` Zi Yan
2026-09-15 17:16 ` [f2fs-dev] " Zi Yan via Linux-f2fs-devel
2026-09-15 18:18 ` Zi Yan via Linux-f2fs-devel
2026-09-14 4:18 ` [PATCH 1/3] md: Use folio_alloc_buffers() Matthew Wilcox (Oracle)
2026-09-14 4:27 ` sashiko-bot
2026-09-14 13:12 ` David Hildenbrand (Arm)
2026-09-14 13:17 ` Matthew Wilcox
2026-09-14 13:20 ` David Hildenbrand (Arm)
2026-09-14 14:36 ` Zi Yan
2026-09-14 4:18 ` [PATCH 2/3] md: Use folio APIs in free_page() Matthew Wilcox (Oracle)
2026-09-14 4:31 ` sashiko-bot
2026-09-14 16:21 ` Matthew Wilcox
2026-09-14 16:25 ` Zi Yan
2026-09-14 13:13 ` David Hildenbrand (Arm)
2026-09-14 4:18 ` [PATCH 3/3] md: Remove the last use of page_buffers() Matthew Wilcox (Oracle)
2026-09-14 4:29 ` sashiko-bot
2026-09-14 13:14 ` David Hildenbrand (Arm)
2026-09-14 4:21 ` [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Matthew Wilcox
2026-09-14 4:21 ` Matthew Wilcox
2026-09-14 4:21 ` [f2fs-dev] " Matthew Wilcox
2026-09-14 13:10 ` David Hildenbrand (Arm)
2026-09-14 13:10 ` David Hildenbrand (Arm)
2026-09-14 13:10 ` [f2fs-dev] " David Hildenbrand (Arm) via Linux-f2fs-devel
2026-09-14 15:30 ` patchwork-bot+f2fs
2026-09-14 15:30 ` patchwork-bot+f2fs
2026-09-14 15:30 ` patchwork-bot+f2fs--- via Linux-f2fs-devel
2026-09-15 21:49 ` Andrew Morton
2026-09-15 23:14 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260914024800.087EF1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=kasong@tencent.com \
--cc=kexec@lists.infradead.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.