From: netdev-bot+sashiko@kernel.org
To: james.hilliard1@gmail.com
Cc: netdev@vger.kernel.org, pabeni@redhat.com, kuba@kernel.org,
magnus.karlsson@intel.com, maciej.fijalkowski@intel.com,
sdf@fomichev.me, horms@kernel.org, ast@kernel.org,
daniel@iogearbox.net, hawk@kernel.org, john.fastabend@gmail.com,
edumazet@kernel.org, davem@davemloft.net, bjorn@kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] xsk: freeze deferred pool teardown without blocking unregister
Date: Mon, 05 Oct 2026 05:31:22 +0000 [thread overview]
Message-ID: <179117828200.434549.5174779969634122541@kernel.org> (raw)
In-Reply-To: <20260930-xsk-suspend-teardown-v1-1-a6cac8c030be@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 0
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] The patch adds one global list, xsk_dev_pools
(net/xdp/xsk_buff_pool.c), that holds every assigned XSK buffer pool…
--
xsk: freeze deferred pool teardown without blocking unregister
This moves deferred XSK buffer pool destruction from system_wq to
system_freezable_wq, so ndo_bpf() is not called on a suspended device. It
also adds a global list of assigned pools. NETDEV_UNREGISTER uses that
list to detach pools whose sockets have already left net->xdp.list.
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 33475b180ea6f..a2ae0e10d8933 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -2145,6 +2145,10 @@ static int xsk_notifier(struct notifier_block *this,
> mutex_unlock(&xs->mutex);
> }
> mutex_unlock(&net->xdp.lock);
> + /* A released socket is no longer on xdp.list. Its pool can still
> + * hold a device reference on the frozen release workqueue.
> + */
> + xp_clear_dev_all(dev);
> break;
> }
> return NOTIFY_DONE;
> diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
> index 9d2d94f1fb759..b5fd0850db5bb 100644
> --- a/net/xdp/xsk_buff_pool.c
> +++ b/net/xdp/xsk_buff_pool.c
> @@ -12,6 +12,11 @@
>
> #define ETH_PAD_LEN (ETH_HLEN + 2 * VLAN_HLEN + ETH_FCS_LEN)
>
> +/* Socket removal precedes the final pool put. Keep assigned pools visible to
> + * NETDEV_UNREGISTER even while their release work is waiting for process thaw.
> + */
> +static LIST_HEAD(xsk_dev_pools);
> +
[ ... ]
> +void xp_clear_dev_all(struct net_device *dev)
> +{
> + struct xsk_buff_pool *pool, *next;
> +
> + ASSERT_RTNL();
> + list_for_each_entry_safe(pool, next, &xsk_dev_pools, dev_list)
> + if (pool->netdev == dev)
> + xp_clear_dev(pool);
> +}
[Severity: Medium]
Should xsk_dev_pools be scoped per netns or per netdev, rather than being
one global list?
As written, xsk_dev_pools holds every assigned pool from every network
namespace. xsk_notifier()->xp_clear_dev_all() walks the whole list under
RTNL on every NETDEV_UNREGISTER, in any namespace.
Before this patch, the notifier only walked net->xdp.list of the namespace
that owns the device. With this change, each unregister costs O(total pools
in the system). A batched unregister, such as netns teardown, costs
O(devices x global pools), all while RTNL is held.
xsk_create() only checks ns_capable(net->user_ns, CAP_NET_RAW). A user
inside a user namespace can therefore create many pools, for example with
copy-mode binds to veth or dummy queues, or with XDP_SHARED_UMEM backing
many pools from one umem. That would lengthen RTNL hold times during device
and netns teardown in unrelated namespaces.
Would tracking the pools per netdev or per netns limit the walk to pools
that can actually match dev?
> static void xp_release_deferred(struct work_struct *work)
> {
> struct xsk_buff_pool *pool = container_of(work, struct xsk_buff_pool,
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260930-xsk-suspend-teardown-v1-1-a6cac8c030be%40gmail.com
prev parent reply other threads:[~2026-10-05 5:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 5:09 James Hilliard
2026-10-01 5:13 ` netdev-bot+sinfo
2026-10-06 4:38 ` James Hilliard
2026-10-05 5:31 ` netdev-bot+sashiko [this message]
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=179117828200.434549.5174779969634122541@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=james.hilliard1@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/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
all inboxes | Powered by JetHome®