From: David Hildenbrand <david@redhat.com>
To: Byungchul Park <byungchul@sk.com>,
linux-mm@kvack.org, netdev@vger.kernel.org
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, hawk@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,
akpm@linux-foundation.org, 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
Subject: Re: [PATCH] mm, page_pool: introduce a new page type for page pool in page type
Date: Mon, 21 Jul 2025 10:05:25 +0200 [thread overview]
Message-ID: <e897e784-4403-467c-b3e4-4ac4dc7b2e25@redhat.com> (raw)
In-Reply-To: <20250721054903.39833-1-byungchul@sk.com>
On 21.07.25 07:49, Byungchul Park wrote:
> Hi,
>
> I focused on converting the existing APIs accessing ->pp_magic field to
> page type APIs. However, yes. Additional works would better be
> considered on top like:
>
> 1. Adjust how to store and retrieve dma index. Maybe network guys
> can work better on top.
>
> 2. Move the sanity check for page pool in mm/page_alloc.c to on free.
>
> Byungchul
>
> ---8<---
> From 7d207a1b3e9f4ff2a72f5b54b09e3ed0c4aaaca3 Mon Sep 17 00:00:00 2001
> From: Byungchul Park <byungchul@sk.com>
> Date: Mon, 21 Jul 2025 14:05:20 +0900
> Subject: [PATCH] mm, page_pool: introduce a new page type for page pool in page type
>
> ->pp_magic field in struct page is current used to identify if a page
> belongs to a page pool. However, page type e.i. PGTY_netpp can be used
> for that purpose.
>
> 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() since they are totally replaced.
>
> This work was inspired by the following link by Pavel:
>
> [1] https://lore.kernel.org/all/582f41c0-2742-4400-9c81-0d46bf4e8314@gmail.com/
I'm, sure you saw my comment (including my earlier suggestion for using
a page type), in particular around ...
> ---
> .../net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +-
> include/linux/mm.h | 28 ++-----------------
> include/linux/page-flags.h | 6 ++++
> include/net/netmem.h | 2 +-
> mm/page_alloc.c | 4 +--
> net/core/netmem_priv.h | 16 ++---------
> net/core/page_pool.c | 10 +++++--
> 7 files changed, 24 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> index 5d51600935a6..def274f5c1ca 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> @@ -707,7 +707,7 @@ static void mlx5e_free_xdpsq_desc(struct mlx5e_xdpsq *sq,
> xdpi = mlx5e_xdpi_fifo_pop(xdpi_fifo);
> page = xdpi.page.page;
>
> - /* No need to check page_pool_page_is_pp() as we
> + /* No need to check PageNetpp() as we
> * know this is a page_pool page.
> */
> page_pool_recycle_direct(pp_page_to_nmdesc(page)->pp,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ae50c1641bed..736061749535 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4135,10 +4135,9 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status);
> * DMA mapping IDs for page_pool
> *
> * When DMA-mapping a page, page_pool allocates an ID (from an xarray) and
> - * stashes it in the upper bits of page->pp_magic. We always want to be able to
> - * unambiguously identify page pool pages (using page_pool_page_is_pp()). Non-PP
> - * pages can have arbitrary kernel pointers stored in the same field as pp_magic
> - * (since it overlaps with page->lru.next), so we must ensure that we cannot
> + * stashes it in the upper bits of page->pp_magic. Non-PP pages can have
> + * arbitrary kernel pointers stored in the same field as pp_magic (since
> + * it overlaps with page->lru.next), so we must ensure that we cannot
> * mistake a valid kernel pointer with any of the values we write into this
> * field.
> *
> @@ -4168,25 +4167,4 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status);
>
> #define PP_DMA_INDEX_MASK GENMASK(PP_DMA_INDEX_BITS + PP_DMA_INDEX_SHIFT - 1, \
> PP_DMA_INDEX_SHIFT)
> -
> -/* Mask used for checking in page_pool_page_is_pp() below. page->pp_magic is
> - * OR'ed with PP_SIGNATURE after the allocation in order to preserve bit 0 for
> - * the head page of compound page and bit 1 for pfmemalloc page, as well as the
> - * bits used for the DMA index. page_is_pfmemalloc() is checked in
> - * __page_pool_put_page() to avoid recycling the pfmemalloc page.
> - */
> -#define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL)
> -
> -#ifdef CONFIG_PAGE_POOL
> -static inline bool page_pool_page_is_pp(const struct page *page)
> -{
> - return (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE;
> -}
> -#else
> -static inline bool page_pool_page_is_pp(const struct page *page)
> -{
> - return false;
> -}
> -#endif
> -
> #endif /* _LINUX_MM_H */
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 4fe5ee67535b..906ba7c9e372 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -957,6 +957,7 @@ enum pagetype {
> PGTY_zsmalloc = 0xf6,
> PGTY_unaccepted = 0xf7,
> PGTY_large_kmalloc = 0xf8,
> + PGTY_netpp = 0xf9,
>
> PGTY_mapcount_underflow = 0xff
> };
> @@ -1101,6 +1102,11 @@ PAGE_TYPE_OPS(Zsmalloc, zsmalloc, zsmalloc)
> PAGE_TYPE_OPS(Unaccepted, unaccepted, unaccepted)
> FOLIO_TYPE_OPS(large_kmalloc, large_kmalloc)
>
> +/*
> + * Marks page_pool allocated pages.
> + */
> +PAGE_TYPE_OPS(Netpp, netpp, netpp)
> +
> /**
> * PageHuge - Determine if the page belongs to hugetlbfs
> * @page: The page to test.
> diff --git a/include/net/netmem.h b/include/net/netmem.h
> index f7dacc9e75fd..3667334e16e7 100644
> --- a/include/net/netmem.h
> +++ b/include/net/netmem.h
> @@ -298,7 +298,7 @@ static inline struct net_iov *__netmem_clear_lsb(netmem_ref netmem)
> */
> #define pp_page_to_nmdesc(p) \
> ({ \
> - DEBUG_NET_WARN_ON_ONCE(!page_pool_page_is_pp(p)); \
> + DEBUG_NET_WARN_ON_ONCE(!PageNetpp(p)); \
> __pp_page_to_nmdesc(p); \
> })
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 2ef3c07266b3..71c7666e48a9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -898,7 +898,7 @@ static inline bool page_expected_state(struct page *page,
> #ifdef CONFIG_MEMCG
> page->memcg_data |
> #endif
> - page_pool_page_is_pp(page) |
> + PageNetpp(page) |
> (page->flags & check_flags)))
> return false;
>
> @@ -925,7 +925,7 @@ 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)))
> + if (unlikely(PageNetpp(page)))
> bad_reason = "page_pool leak";
> return bad_reason;
> }
^ this
This will not work they way you want it once you rebase on top of
linux-next, where we have (from mm/mm-stable)
commit 2dfcd1608f3a96364f10de7fcfe28727c0292e5d
Author: David Hildenbrand <david@redhat.com>
Date: Fri Jul 4 12:24:58 2025 +0200
mm/page_alloc: let page freeing clear any set page type
I commented what to do already.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-07-21 8:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 5:49 Byungchul Park
2025-07-21 8:05 ` David Hildenbrand [this message]
2025-07-21 8:19 ` Byungchul Park
2025-07-21 8:49 ` David Hildenbrand
2025-07-22 1:04 ` Byungchul Park
2025-07-28 10:57 ` Byungchul Park
2025-07-21 11:12 ` Pavel Begunkov
2025-07-22 1:03 ` Byungchul Park
2025-07-22 22:20 ` Mina Almasry
2025-07-22 22:17 ` Mina Almasry
2025-07-23 4:46 ` Byungchul Park
2025-07-24 21:23 ` Mina Almasry
2025-07-25 0:26 ` Byungchul Park
2025-07-25 6:50 ` Byungchul Park
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=e897e784-4403-467c-b3e4-4ac4dc7b2e25@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--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=edumazet@google.com \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=hawk@kernel.org \
--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=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