Netdev List
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: kuniyu@google.com
Cc: dsahern@kernel.org, idosch@nvidia.com, davem@davemloft.net,
	edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, carges@cloudflare.com, kuni1840@gmail.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH v1 net-next 2/5] net: Add ->pre_exit_batch() to struct pernet_operations.
Date: Tue, 29 Sep 2026 06:26:52 +0000	[thread overview]
Message-ID: <179066321227.434549.13771615629655873291@kernel.org> (raw)
In-Reply-To: <20260927202429.2452589-3-kuniyu@google.com>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The new ->pre_exit_batch() hook is undocumented, and the commit
  message describes its scope inaccurately.

--

net: Add ->pre_exit_batch() to struct pernet_operations.

This commit adds a pre_exit_batch() callback to struct pernet_operations.
ops_pre_exit_list() calls it after the per-net pre_exit() calls. The goal
is to let subsystems batch device-related cleanup, such as flushing
uncached routes, across dying namespaces without holding RTNL and before
ops_exit_rtnl_list().

> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index b4247e767d135..58b2601bb8691 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -488,6 +488,7 @@ struct pernet_operations {
>  	 */
>  	int (*init)(struct net *net);
>  	void (*pre_exit)(struct net *net);
> +	void (*pre_exit_batch)(struct list_head *net_exit_list);
>  	void (*exit)(struct net *net);
>  	void (*exit_batch)(struct list_head *net_exit_list);
>  	/* Following method is called with RTNL held. */
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 0e13de0cd36b6..476fbf913bad8 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -160,6 +160,9 @@ static void ops_pre_exit_list(const struct pernet_operations *ops,
>  		list_for_each_entry(net, net_exit_list, exit_list)
>  			ops->pre_exit(net);
>  	}
> +
> +	if (ops->pre_exit_batch)
> +		ops->pre_exit_batch(net_exit_list);

[Severity: Low]
The commit message says the hook is there "To batch such cleanup across
dying netns". Is net_exit_list here always a list of dying namespaces?

ops_pre_exit_list() is also reached through ops_undo_single() from
__unregister_pernet_operations(). That function builds the list from every
live netns, including init_net:

net/core/net_namespace.c:__unregister_pernet_operations() {
    ...
	for_each_net(net)
		list_add_tail(&net->exit_list, &net_exit_list);

	list_del(&ops->list);
	ops_undo_single(ops, &net_exit_list);
}

It is also reached from the error path of __register_pernet_operations().
It is reached from the setup_net() failure path through ops_undo_list() as
well, and there check_net() is still true for the net being torn down.

The two users later in this series seem to cope with this by ignoring the
list and filtering on !check_net(). Could the commit message be updated to
describe the scope the hook actually has?

Separately, the comment block above struct pernet_operations describes
how pre_exit(), exit() and exit_batch() are ordered and where
synchronize_rcu() falls between them. It is not updated for the new
member.

Would it make sense to document the following there?

  - pre_exit_batch() runs after all pre_exit() calls for the same ops.
  - It runs before the synchronize_rcu() that comes ahead of exit_rtnl(),
    exit() and exit_batch().
  - It runs while the netns devices may still be registered and up.
  - net_exit_list may contain live namespaces.

There is a related and more speculative case later in the series. The
change "net: Track state in ops_undo_list()" marks nets as
NET_PRE_EXIT_DONE whenever ops_list == &pernet_list. That includes the
setup_net() out_undo path, where check_net(net) is true.

In that case, rt_flush_dev(NULL) and rt6_uncached_list_flush_dev(NULL)
would skip that net's routes because check_net() is true. The per-device
flush on NETDEV_UNREGISTER would then return early because
net_pre_exit_done() is true.

If an uncached route pointing at a device of the failing netns existed at
that point, would its device reference ever be released? It is not clear
that such a route can exist in a netns that is not yet visible, so this
may not be reachable.

>  }
>  
>  static void ops_exit_rtnl_list(const struct list_head *ops_list,

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260927202429.2452589-1-kuniyu%40google.com

  reply	other threads:[~2026-09-29  6:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-27 20:23 [PATCH v1 net-next 0/5] ip: Batch flushing uncached routes for dying netns Kuniyuki Iwashima
2026-09-27 20:23 ` [PATCH v1 net-next 1/5] net: Remove net->is_dying Kuniyuki Iwashima
2026-09-29  6:26   ` netdev-bot+sashiko
2026-09-27 20:23 ` [PATCH v1 net-next 2/5] net: Add ->pre_exit_batch() to struct pernet_operations Kuniyuki Iwashima
2026-09-29  6:26   ` netdev-bot+sashiko [this message]
2026-09-27 20:23 ` [PATCH v1 net-next 3/5] net: Track state in ops_undo_list() Kuniyuki Iwashima
2026-09-27 20:23 ` [PATCH v1 net-next 4/5] ipv4: Batch rt_flush_dev() for dying netns Kuniyuki Iwashima
2026-09-27 22:51   ` Eric Dumazet
2026-09-28 16:33     ` Kuniyuki Iwashima
2026-09-29  6:26   ` netdev-bot+sashiko
2026-09-27 20:23 ` [PATCH v1 net-next 5/5] ipv6: Batch rt6_uncached_list_flush_dev() " Kuniyuki Iwashima
2026-09-29  6:26   ` netdev-bot+sashiko

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=179066321227.434549.13771615629655873291@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=carges@cloudflare.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=kuni1840@gmail.com \
    --cc=kuniyu@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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