Re: [PATCH net-next 6/6] net: document NETDEV_UNREGISTER unlocked rationale

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 1 Jul 2026 09:02:27 -0700 Stanislav Fomichev wrote:
> On 06/30, Jakub Kicinski wrote:
> > On Tue, 30 Jun 2026 11:21:29 -0700 Stanislav Fomichev wrote:  
> > > +Many ``NETDEV_UNREGISTER`` handlers release their lowers with
> > > +``dev_close()``, which takes the instance lock itself. Holding
> > > +the lock across UNREGISTER would deadlock.
> > > +
> > > +Moving UNREGISTER under the lock is mechanical: switch those
> > > +callers to the ``netif_*()`` lock-held variants. Deferred to
> > > +limit churn.  
> 
> > Doing anything with the device that is sending the UNREGISTER
> > sounds odd, since it's going away..  
> 
> Looking at __bond_release_one, it does try to restore a few original
> settings, mostly mtu, I think? (And it does call dev_close unconditionally,
> that's fixable).
> 
> bond_netdev_event
>   bond_slave_netdev_event(slave_dev=event_dev)
>     __bond_release_one
>       {__netif,dev}_set_mtu(slave_dev, slave->original_mtu)
> 
> Or am I misreading this part?

Oh, I see. I guess it's pointless to restore on unregistered
device but I guess it's not illegal so maybe not worth the
complexity of a skip..

> > Not following TBH. Let's say there's a UNREGISTER ntf for eth0.
> > Are you saying that eg. vlan which closes their own vlan0 devices
> > on top of eth0 needs to be switched to netif_ ? That wouldn't make
> > sense since the notification is holding netdev_lock(eth0) and
> > we're talking about netif_close(vlan0)?  
> 
> Maybe rewording it to `... UNREGISTER handlers interact with their
> lowers using dev_xxx handlers which take the instance lock` ?
> 
> I'm mainly looking for an excuse/explanation on why UNREGISTER
> is not converted in this series. Or should I bite the bullet and
> add a few patches to make UNREGISTER ops locked as well?

The documentation is fine. Just need a better phrasing, I guess.