Thread (10 messages) 10 messages, 2 authors, 1d ago

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

From: Stanislav Fomichev <hidden>
Date: 2026-07-01 16:02:34

On 06/30, Jakub Kicinski wrote:
On Tue, 30 Jun 2026 11:21:29 -0700 Stanislav Fomichev wrote:
quoted
+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?
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help