From: James Hilliard <james.hilliard1@gmail.com>
To: "Russell King" <linux@armlinux.org.uk>,
"Andrew Lunn" <andrew@lunn.ch>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Joakim Zhang" <qiangqing.zhang@nxp.com>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Christian Marangi" <ansuelsmth@gmail.com>,
"Tiezhu Yang" <yangtiezhu@loongson.cn>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Serge Semin" <fancer.lancer@gmail.com>,
"Suraj Jaiswal" <quic_jsuraj@quicinc.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Joao Pinto" <Joao.Pinto@synopsys.com>,
"Vladimir Oltean" <vladimir.oltean@nxp.com>,
"Ong Boon Leong" <boon.leong.ong@intel.com>,
"Voon Weifeng" <weifeng.voon@intel.com>,
"Song, Yoong Siang" <yoong.siang.song@intel.com>,
"Linus Walleij" <linusw@kernel.org>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
"Simon Horman" <horms@kernel.org>,
"Björn Töpel" <bjorn@kernel.org>,
"Thierry Reding" <thierry.reding@kernel.org>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Chen-Yu Tsai" <wens@kernel.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Samuel Holland" <samuel@sholland.org>,
"Eric Dumazet" <edumazet@kernel.org>
Cc: Richard Genoud <richard.genoud@bootlin.com>,
Alastair D'Silva <alastair@d-silva.org>,
Maxime Ripard <mripard@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org,
ZhaoJinming <zhaojinming@uniontech.com>,
Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>,
Ding Hui <dinghui1111@163.com>,
James Hilliard <james.hilliard1@gmail.com>,
linux-tegra@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: [PATCH net v4 12/15] xsk: allow drivers to retain DMA mappings independently of pools
Date: Sat, 26 Sep 2026 09:49:07 -0600 [thread overview]
Message-ID: <20260926-submit-stmmac-reset-fixes-v1-v4-12-ec1c0250b3c9@gmail.com> (raw)
In-Reply-To: <20260926-submit-stmmac-reset-fixes-v1-v4-0-ec1c0250b3c9@gmail.com>
An unsuccessful device shutdown does not make its DMA memory safe to
unmap. AF_XDP pool removal must nevertheless complete: the last socket
release invokes the driver detach callback and then destroys the pool,
regardless of the callback's return value.
Provide an independent reference to the existing DMA mapping and its
UMEM pages. A driver can take it while installing rings and release it
after DMA has actually stopped. It does not retain pool metadata, fill
or completion rings, or the pool users reference which triggers
teardown.
Keep the DMA device and the mapping's netdev lookup key allocated,
without taking a netdev usage reference that would prevent unregister.
Save the mapping attributes and unmap before dropping the last retained
UMEM reference. Mapping reference operations are serialized by RTNL,
like the existing mapping list operations.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
include/net/xdp_sock_drv.h | 23 ++++++++++++++++++++++
include/net/xsk_buff_pool.h | 4 ++++
net/xdp/xsk_buff_pool.c | 48 +++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h
index d94aeb506379..819410797db3 100644
--- a/include/net/xdp_sock_drv.h
+++ b/include/net/xdp_sock_drv.h
@@ -95,6 +95,20 @@ static inline void xsk_pool_dma_unmap(struct xsk_buff_pool *pool,
xp_dma_unmap(pool, attrs);
}
+/* RTNL must be held. Keep DMA mappings and pinned pages independently of
+ * the socket/pool lifetime, for rings whose DMA shutdown can fail.
+ * This does not keep pool metadata alive or postpone the detach callback.
+ */
+static inline struct xsk_dma_map *xsk_pool_dma_get(struct xsk_buff_pool *pool)
+{
+ return xp_dma_get(pool);
+}
+
+static inline void xsk_pool_dma_put(struct xsk_dma_map *dma_map)
+{
+ xp_dma_put(dma_map);
+}
+
static inline int xsk_pool_dma_map(struct xsk_buff_pool *pool,
struct device *dev, unsigned long attrs)
{
@@ -432,6 +446,15 @@ static inline void xsk_pool_dma_unmap(struct xsk_buff_pool *pool,
{
}
+static inline struct xsk_dma_map *xsk_pool_dma_get(struct xsk_buff_pool *pool)
+{
+ return NULL;
+}
+
+static inline void xsk_pool_dma_put(struct xsk_dma_map *dma_map)
+{
+}
+
static inline int xsk_pool_dma_map(struct xsk_buff_pool *pool,
struct device *dev, unsigned long attrs)
{
diff --git a/include/net/xsk_buff_pool.h b/include/net/xsk_buff_pool.h
index a7df573784fd..25a09b098703 100644
--- a/include/net/xsk_buff_pool.h
+++ b/include/net/xsk_buff_pool.h
@@ -38,6 +38,8 @@ struct xsk_dma_map {
dma_addr_t *dma_pages;
struct device *dev;
struct net_device *netdev;
+ struct xdp_umem *umem;
+ unsigned long attrs;
refcount_t users;
struct list_head list; /* Protected by the RTNL_LOCK */
u32 dma_pages_cnt;
@@ -143,6 +145,8 @@ void xp_fill_cb(struct xsk_buff_pool *pool, struct xsk_cb_desc *desc);
int xp_dma_map(struct xsk_buff_pool *pool, struct device *dev,
unsigned long attrs, struct page **pages, u32 nr_pages);
void xp_dma_unmap(struct xsk_buff_pool *pool, unsigned long attrs);
+struct xsk_dma_map *xp_dma_get(struct xsk_buff_pool *pool);
+void xp_dma_put(struct xsk_dma_map *dma_map);
struct xdp_buff *xp_alloc(struct xsk_buff_pool *pool);
u32 xp_alloc_batch(struct xsk_buff_pool *pool, struct xdp_buff **xdp, u32 max);
bool xp_can_alloc(struct xsk_buff_pool *pool, u32 count);
diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
index c58f56f24a9c..8f95eddc91fc 100644
--- a/net/xdp/xsk_buff_pool.c
+++ b/net/xdp/xsk_buff_pool.c
@@ -360,7 +360,8 @@ static struct xsk_dma_map *xp_find_dma_map(struct xsk_buff_pool *pool)
}
static struct xsk_dma_map *xp_create_dma_map(struct device *dev, struct net_device *netdev,
- u32 nr_pages, struct xdp_umem *umem)
+ u32 nr_pages, struct xdp_umem *umem,
+ unsigned long attrs)
{
struct xsk_dma_map *dma_map;
@@ -376,6 +377,8 @@ static struct xsk_dma_map *xp_create_dma_map(struct device *dev, struct net_devi
dma_map->netdev = netdev;
dma_map->dev = dev;
+ dma_map->umem = umem;
+ dma_map->attrs = attrs;
dma_map->dma_pages_cnt = nr_pages;
refcount_set(&dma_map->users, 1);
list_add(&dma_map->list, &umem->xsk_dma_list);
@@ -430,6 +433,47 @@ void xp_dma_unmap(struct xsk_buff_pool *pool, unsigned long attrs)
}
EXPORT_SYMBOL(xp_dma_unmap);
+struct xsk_dma_map *xp_dma_get(struct xsk_buff_pool *pool)
+{
+ struct xsk_dma_map *dma_map;
+
+ ASSERT_RTNL();
+ if (!pool->dma_pages)
+ return NULL;
+ dma_map = xp_find_dma_map(pool);
+ if (WARN_ON_ONCE(!dma_map))
+ return NULL;
+
+ refcount_inc(&dma_map->users);
+ xdp_get_umem(dma_map->umem);
+ get_device(dma_map->dev);
+ /* Keep the mapping's lookup key alive without preventing unregister. */
+ get_device(&dma_map->netdev->dev);
+ return dma_map;
+}
+EXPORT_SYMBOL_GPL(xp_dma_get);
+
+void xp_dma_put(struct xsk_dma_map *dma_map)
+{
+ struct net_device *netdev;
+ struct xdp_umem *umem;
+ struct device *dev;
+
+ ASSERT_RTNL();
+ if (!dma_map)
+ return;
+ dev = dma_map->dev;
+ netdev = dma_map->netdev;
+ umem = dma_map->umem;
+ if (refcount_dec_and_test(&dma_map->users))
+ __xp_dma_unmap(dma_map, dma_map->attrs);
+ /* Unmap before the final reference can unpin the UMEM pages. */
+ xdp_put_umem(umem, false);
+ put_device(&netdev->dev);
+ put_device(dev);
+}
+EXPORT_SYMBOL_GPL(xp_dma_put);
+
static void xp_check_dma_contiguity(struct xsk_dma_map *dma_map)
{
u32 i;
@@ -487,7 +531,7 @@ int xp_dma_map(struct xsk_buff_pool *pool, struct device *dev,
return 0;
}
- dma_map = xp_create_dma_map(dev, pool->netdev, nr_pages, pool->umem);
+ dma_map = xp_create_dma_map(dev, pool->netdev, nr_pages, pool->umem, attrs);
if (!dma_map)
return -ENOMEM;
--
2.53.0
next prev parent reply other threads:[~2026-09-26 15:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-26 15:48 [PATCH net v4 00/15] net: stmmac: preserve datapath state across MTU and resume failures James Hilliard
2026-09-26 15:48 ` [PATCH net v4 01/15] net: stmmac: unwind the WoL IRQ after a safety IRQ request failure James Hilliard
2026-09-26 15:48 ` [PATCH net v4 02/15] net: stmmac: reuse the MDIO reset GPIO on resume James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:48 ` [PATCH net v4 03/15] net: phylink: allow stopping a suspended instance James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:48 ` [PATCH net v4 04/15] xsk: freeze deferred pool teardown during system sleep James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 05/15] net: stmmac: serialize and retain PHC configuration across reset James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 06/15] net: stmmac: leave the datapath running for normal-size MTU changes James Hilliard
2026-09-26 15:49 ` [PATCH net v4 07/15] net: stmmac: unwind partially allocated DMA configurations James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 08/15] net: stmmac: keep DMA configurations at stable addresses James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 09/15] net: stmmac: track datapath and power ownership across failed reopening James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 10/15] net: stmmac: use the tracked datapath restart for XSK pool changes James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 11/15] net: stmmac: restore TC offloads before restarting DMA James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` James Hilliard [this message]
2026-09-26 15:49 ` [PATCH net v4 13/15] net: stmmac: retain DMA memory until hardware shutdown completes James Hilliard
2026-09-30 4:51 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 14/15] net: stmmac: prepare device-local DMA interrupt quiescence James Hilliard
2026-09-30 4:52 ` netdev-bot+sashiko
2026-09-26 15:49 ` [PATCH net v4 15/15] net: stmmac: retain DMA resources across MTU changes James Hilliard
2026-09-30 4:52 ` netdev-bot+sashiko
2026-09-26 16:00 ` [PATCH net v4 00/15] net: stmmac: preserve datapath state across MTU and resume failures Maxime Chevallier
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=20260926-submit-stmmac-reset-fixes-v1-v4-12-ec1c0250b3c9@gmail.com \
--to=james.hilliard1@gmail.com \
--cc=Joao.Pinto@synopsys.com \
--cc=alastair@d-silva.org \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=boon.leong.ong@intel.com \
--cc=bpf@vger.kernel.org \
--cc=chenhuacai@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dinghui1111@163.com \
--cc=edumazet@kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=hawk@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=jernej.skrabec@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kuba@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo.bianconi@oss.qualcomm.com \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mripard@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qiangqing.zhang@nxp.com \
--cc=quic_jsuraj@quicinc.com \
--cc=richard.genoud@bootlin.com \
--cc=richardcochran@gmail.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=samuel@sholland.org \
--cc=sdf@fomichev.me \
--cc=thierry.reding@kernel.org \
--cc=vladimir.oltean@nxp.com \
--cc=weifeng.voon@intel.com \
--cc=wens@kernel.org \
--cc=yangtiezhu@loongson.cn \
--cc=yoong.siang.song@intel.com \
--cc=zhaojinming@uniontech.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