Re: [PATCH net-next 0/4] net: reduce RTNL pressure in unregister_netdevice()

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 7 Jan 2025 21:46:41 +0100 Eric Dumazet wrote:
> > > I think we'll need:
> > >
> > > diff --git a/net/devlink/port.c b/net/devlink/port.c
> > > index 939081a0e615..cdfa22453a55 100644
> > > --- a/net/devlink/port.c
> > > +++ b/net/devlink/port.c
> > > @@ -1311,6 +1311,7 @@ int devlink_port_netdevice_event(struct notifier_block *nb,
> > >                 __devlink_port_type_set(devlink_port, devlink_port->type,
> > >                                         netdev);
> > >                 break;
> > > +       case NETDEV_UNREGISTERING:  
> >
> > Not sure I follow ?

I was worried some code assumed devlink_port->netdev is safe to access
under rtnl_lock. But looking closer it's only used in trivial ways, so
you can ignore that.

> > >         case NETDEV_UNREGISTER:
> > >                 if (devlink_net(devlink) != dev_net(netdev))
> > >                         return NOTIFY_OK;
> > >
> > >
> > > There is no other way to speed things up? Use RT prio for the work?
> > > Maybe WRITE_ONCE() a special handler into backlog.poll, and schedule it?
> > >
> > > I'm not gonna stand in your way but in general re-taking caller locks
> > > in a callee is a bit ugly :(  
> >
> > We might restrict this stuff to cleanup_net() caller only, we know the
> > netns are disappearing and that no other thread can mess with them.  

Unless the interface has a peer in another netns. But that should be
fine, interface will be de-listed. I'm slightly more concerned that some
random code in the kernel assumes its stashed netdev pointer to be valid
under rtnl_lock, as long as it has not seen an NETDEV_UNREGISTER event.
I guess we'll find out..? :)

> ie something like:
> [...]

LGTM!