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: 29+ 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
2026-05-13 9:00 ` [PATCH v4] " Dragos Tatulea
2026-05-13 9:12 ` Vlastimil Babka (SUSE)
2026-05-13 9:26 ` Pedro Falcato
2026-05-13 9:36 ` David Hildenbrand (Arm)
2026-05-13 12:06 ` Dragos Tatulea
2026-05-13 12:11 ` David Hildenbrand (Arm)
2026-05-14 8:54 ` Byungchul Park
2026-05-14 9:24 ` Dragos Tatulea
2026-05-15 0:01 ` Byungchul Park
2026-05-13 9:34 ` David Hildenbrand (Arm)
2026-05-13 12:18 ` Byungchul Park
2026-05-13 12:29 ` David Hildenbrand (Arm)
2026-05-13 12:39 ` Byungchul Park
2026-05-13 13:02 ` David Hildenbrand (Arm)
2026-05-13 13:26 ` Byungchul Park
2026-05-13 9:42 ` Lorenzo Stoakes
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 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.