From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Byungchul Park <byungchul@sk.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
Mina Almasry <almasrymina@google.com>,
Toke Hoiland Jorgensen <toke@redhat.com>
Cc: linux-kernel@vger.kernel.org, kernel_team@skhynix.com,
harry.yoo@oracle.com, ast@kernel.org, daniel@iogearbox.net,
davem@davemloft.net, kuba@kernel.org, john.fastabend@gmail.com,
sdf@fomichev.me, saeedm@nvidia.com, leon@kernel.org,
tariqt@nvidia.com, mbloch@nvidia.com, andrew+netdev@lunn.ch,
edumazet@google.com, pabeni@redhat.com, david@redhat.com,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, horms@kernel.org, jackmanb@google.com,
hannes@cmpxchg.org, ziy@nvidia.com, ilias.apalodimas@linaro.org,
willy@infradead.org, brauner@kernel.org, kas@kernel.org,
yuzhao@google.com, usamaarif642@gmail.com,
baolin.wang@linux.alibaba.com, almasrymina@google.com,
toke@redhat.com, asml.silence@gmail.com, bpf@vger.kernel.org,
linux-rdma@vger.kernel.org, sfr@canb.auug.org.au, dw@davidwei.uk,
ap420073@gmail.com, dtatulea@nvidia.com
Subject: Re: [PATCH v5] mm: introduce a new page type for page pool in page type
Date: Tue, 17 Mar 2026 10:20:08 +0100 [thread overview]
Message-ID: <ebd00055-d4aa-4612-8bf3-ef0a308512f8@kernel.org> (raw)
In-Reply-To: <20260316223113.20097-1-byungchul@sk.com>
On 16/03/2026 23.31, Byungchul Park wrote:
> Currently, the condition 'page->pp_magic == PP_SIGNATURE' is used to
> determine if a page belongs to a page pool. However, with the planned
> removal of @pp_magic, we should instead leverage the page_type in struct
> page, such as PGTY_netpp, for this purpose.
>
> Introduce and use the page type APIs e.g. PageNetpp(), __SetPageNetpp(),
> and __ClearPageNetpp() instead, and remove the existing APIs accessing
> @pp_magic e.g. page_pool_page_is_pp(), netmem_or_pp_magic(), and
> netmem_clear_pp_magic().
>
> Plus, add @page_type to struct net_iov at the same offset as struct page
> so as to use the page_type APIs for struct net_iov as well. While at it,
> reorder @type and @owner in struct net_iov to avoid a hole and
> increasing the struct size.
>
> This work was inspired by the following link:
>
> https://lore.kernel.org/all/582f41c0-2742-4400-9c81-0d46bf4e8314@gmail.com/
>
> While at it, move the sanity check for page pool to on the free path.
>
[...]
see below
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 9f2fe46ff69a1..ee81f5c67c18f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1044,7 +1044,6 @@ static inline bool page_expected_state(struct page *page,
> #ifdef CONFIG_MEMCG
> page->memcg_data |
> #endif
> - page_pool_page_is_pp(page) |
> (page->flags.f & check_flags)))
> return false;
>
> @@ -1071,8 +1070,6 @@ static const char *page_bad_reason(struct page *page, unsigned long flags)
> if (unlikely(page->memcg_data))
> bad_reason = "page still charged to cgroup";
> #endif
> - if (unlikely(page_pool_page_is_pp(page)))
> - bad_reason = "page_pool leak";
> return bad_reason;
> }
>
> @@ -1381,9 +1378,17 @@ __always_inline bool __free_pages_prepare(struct page *page,
> mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
> folio->mapping = NULL;
> }
> - if (unlikely(page_has_type(page)))
> + if (unlikely(page_has_type(page))) {
> + /* networking expects to clear its page type before releasing */
> + if (is_check_pages_enabled()) {
> + if (unlikely(PageNetpp(page))) {
> + bad_page(page, "page_pool leak");
> + return false;
> + }
> + }
> /* Reset the page_type (which overlays _mapcount) */
> page->page_type = UINT_MAX;
> + }
I need some opinions here. When CONFIG_DEBUG_VM is enabled we get help
finding (hard to find) page_pool leaks and mark the page as bad.
When CONFIG_DEBUG_VM is disabled we silently "allow" leaking.
Should we handle this more gracefully here? (release pp resources)
Allowing the page to be reused at this point, when a page_pool instance
is known to track life-time and (likely) have the page DMA mapped, seems
problematic to me. Code only clears page->page_type, but IIRC Toke
added DMA tracking in other fields (plus xarray internally).
I was going to suggest to simply re-export page_pool_release_page() that
was hidden by 535b9c61bdef ("net: page_pool: hide
page_pool_release_page()"), but that functionality was lost in
07e0c7d3179d ("net: page_pool: merge page_pool_release_page() with
page_pool_return_page()"). (Cc Jakub/Kuba for that choice).
Simply page_pool_release_page(page->pp, page).
Opinions?
--Jesper
next prev parent reply other threads:[~2026-03-17 9:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 5:13 [PATCH v4] mm: introduce a new page type for page pool in page type Byungchul Park
2026-02-25 7:19 ` Mike Rapoport
2026-02-26 18:49 ` Johannes Weiner
2026-03-16 22:29 ` Byungchul Park
2026-03-16 22:31 ` [PATCH v5] " Byungchul Park
2026-03-17 9:20 ` Jesper Dangaard Brouer [this message]
2026-03-17 10:03 ` Ilias Apalodimas
2026-03-17 11:06 ` Dragos Tatulea
2026-03-19 23:31 ` Jakub Kicinski
2026-03-18 2:02 ` Byungchul Park
2026-03-20 11:44 ` Jesper Dangaard Brouer
2026-03-23 12:16 ` Ilias Apalodimas
2026-03-19 23:31 ` Jakub Kicinski
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=ebd00055-d4aa-4612-8bf3-ef0a308512f8@kernel.org \
--to=hawk@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=ap420073@gmail.com \
--cc=asml.silence@gmail.com \
--cc=ast@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=byungchul@sk.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=dtatulea@nvidia.com \
--cc=dw@davidwei.uk \
--cc=edumazet@google.com \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=horms@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jackmanb@google.com \
--cc=john.fastabend@gmail.com \
--cc=kas@kernel.org \
--cc=kernel_team@skhynix.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mbloch@nvidia.com \
--cc=mhocko@suse.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rppt@kernel.org \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--cc=sfr@canb.auug.org.au \
--cc=surenb@google.com \
--cc=tariqt@nvidia.com \
--cc=toke@redhat.com \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=yuzhao@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox