From: Paolo Abeni <pabeni@redhat.com>
To: Kuniyuki Iwashima <kuniyu@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>
Cc: Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuni1840@gmail.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH v1 net-next 3/3] geneve: Support per-netns netdev unregistration.
Date: Tue, 4 Aug 2026 15:47:22 +0200 [thread overview]
Message-ID: <bfa765c2-a3e7-42b7-90c5-9757d8392687@redhat.com> (raw)
In-Reply-To: <20260731164612.2148830-4-kuniyu@google.com>
On 7/31/26 6:45 PM, Kuniyuki Iwashima wrote:
> geneve_exit_rtnl_net() iterates geneve devices whose sockets
> are in the dying netns and queues them for destruction.
>
> So the devices may reside in different netns.
>
> Let's use unregister_netdevice_queue_net() to support per-netns
> device unregistration.
>
> list_del() is changed to list_del_init() to avoid queueing the
> same device twice.
>
> Even after geneve_exit_rtnl_net() queues a cross-netns geneve
> device, geneve_dellink() can be called concurrently for it.
> In such a case, __rtnl_net_unlock() will perform the unregistration.
>
> Note that geneve uses register_pernet_subsys() instead of _device(),
> so default_device_exit_batch() guarantees that the async per-netns
> works are flushed before ->exit().
>
> Tested:
>
> 1. Create geneve device across two netns.
>
> # ip netns add ns1
> # ip netns add ns2
> # ip -n ns1 link add geneve0 link-netns ns2 type geneve external
>
> 2. Run bpftrace to check that geneve_uninit() is called between
> ->exit_rtnl() and ->exit().
>
> # bpftrace -e '#include <linux/netdevice.h>
> kprobe:geneve_uninit {
> $dev = (struct net_device *)arg0;
> printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
> }
> kprobe:geneve_exit_rtnl_net,
> kprobe:geneve_exit_net {
> printf("PID: %d%s\n", pid, kstack());
> }'
>
> 3. Remove the netns where the geneve socket resides
>
> # ip netns del ns2
>
> Now, we can see geneve0 is unregistered by per-netns work
> instead of cleanup_net() and it finishes before ->exit() to
> avoid WARN_ON_ONCE(!list_empty(&gn->sock_list)) there.
>
> PID: 571
> geneve_exit_rtnl_net+5
> ops_undo_list+702
> cleanup_net+1122
> process_scheduled_works+2538
> ...
> PID: 1047 | DEV: geneve0
> geneve_uninit+5
> unregister_netdevice_many_notify+7129
> unregister_netdevice_many_net+1050
> rtnl_net_work_func+136
> process_scheduled_works+2538
> ...
> PID: 571
> geneve_exit_net+5
> ops_undo_list+1064
> cleanup_net+1122
> process_scheduled_works+2538
> ...
>
> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
> ---
> drivers/net/geneve.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index f456a85dca77..a6a8978e3b81 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -2502,12 +2502,13 @@ static int geneve_changelink(struct net_device *dev, struct nlattr *tb[],
> return err;
> }
>
> -static void __geneve_dellink(struct net_device *dev, struct list_head *head)
> +static void __geneve_dellink(struct net *net, struct net_device *dev,
> + struct list_head *head)
> {
> struct geneve_dev *geneve = netdev_priv(dev);
>
> - list_del(&geneve->next);
> - unregister_netdevice_queue(dev, head);
> + list_del_init(&geneve->next);
> + unregister_netdevice_queue_net(net, dev, head);
> }
>
> static void geneve_dellink(struct net_device *dev, struct list_head *head)
> @@ -2518,7 +2519,8 @@ static void geneve_dellink(struct net_device *dev, struct list_head *head)
> gn = net_generic(geneve->net, geneve_net_id);
>
> mutex_lock(&gn->lock);
> - __geneve_dellink(dev, head);
> + if (!list_empty(&geneve->next))
> + __geneve_dellink(dev_net(dev), dev, head);
Sashiko noted that the lockdep chain between dev->lock, utn->loc and
gn->lock is not trivial, possibly a documentation follow-up would be useful
> mutex_unlock(&gn->lock);
> }
>
> @@ -2754,7 +2756,7 @@ static void __net_exit geneve_exit_rtnl_net(struct net *net,
> mutex_lock(&gn->lock);
>
> list_for_each_entry_safe(geneve, next, &gn->geneve_list, next)
> - __geneve_dellink(geneve->dev, dev_to_kill);
> + __geneve_dellink(net, geneve->dev, dev_to_kill);
Here sashiko foresees some problem with CONFIG_DEBUG_NET_SMALL_RTNL
before full conversion to per netns lock even of ovs. Just more
follow-up, I guess.
/P
>
> mutex_unlock(&gn->lock);
> }
next prev parent reply other threads:[~2026-08-04 13:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 16:45 [PATCH v1 net-next 0/3] geneve: Support per-netns device unregistration Kuniyuki Iwashima
2026-07-31 16:45 ` [PATCH v1 net-next 1/3] geneve: Unlink geneve->sock[46].hlist[46].hlist in __geneve_sock_release() Kuniyuki Iwashima
2026-07-31 16:45 ` [PATCH v1 net-next 2/3] geneve: Protect geneve_net and geneve_sock with per-netns mutex Kuniyuki Iwashima
2026-07-31 16:45 ` [PATCH v1 net-next 3/3] geneve: Support per-netns netdev unregistration Kuniyuki Iwashima
2026-08-04 13:47 ` Paolo Abeni [this message]
2026-08-04 15:24 ` Kuniyuki Iwashima
2026-08-04 15:35 ` Ilya Maximets
2026-08-04 17:38 ` Kuniyuki Iwashima
2026-08-04 17:34 ` Paolo Abeni
2026-08-04 17:37 ` Kuniyuki Iwashima
2026-08-04 14:00 ` [PATCH v1 net-next 0/3] geneve: Support per-netns device unregistration patchwork-bot+netdevbpf
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=bfa765c2-a3e7-42b7-90c5-9757d8392687@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=kuniyu@google.com \
--cc=netdev@vger.kernel.org \
/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