net: avoid nested UP notifier events

The rx_mode update runs from a workqueue: drivers have their ndo_set_rx_mode_async() callback executed by a single global work item under RTNL and ops lock. This is a useful pattern.

Support multiple "events" that need to be serviced and make RX_MODE sync the first one. Call the events "core" because later on we will let drivers define and schedule their own.

Signed-off-by Jakub Kicinski <[email protected]>

Oh very nice !

I was drafting almost the same change for dev_set_rx_mode() in mcast path and some ipvlan changes.

The rx_mode update runs from a workqueue: drivers have their ndo_set_rx_mode_async() callback executed by a single global work item under RTNL and ops lock. This is a useful pattern.

Support multiple "events" that need to be serviced and make RX_MODE sync the first one. Call the events "core" because later on we will let drivers define and schedule their own.

Signed-off-by Jakub Kicinski <[email protected]>

With an extra event mask we can easily extend the netdev work to also service driver-defined events. For advanced drivers this is probably not a perfect match, but it makes running deferred work easier in simple cases.

Expose the netdev_work facility to drivers. Add helpers to schedule work and a dedicated ndo to perform the driver- -scheduled actions.

Signed-off-by Jakub Kicinski <[email protected]>

With an extra event mask we can easily extend the netdev work to also service driver-defined events. For advanced drivers this is probably not a perfect match, but it makes running deferred work easier in simple cases.

Expose the netdev_work facility to drivers. Add helpers to schedule work and a dedicated ndo to perform the driver- -scheduled actions.

Signed-off-by Jakub Kicinski <[email protected]>

vlan_device_event() generates nested UP/DOWN, MTU and feature change events. It executes an event for the VLAN device directly from the notifier - while the locks of the lower device are held.

This causes deadlocks, for example:

bond (3) bond_update_speed_duplex(vlan)
| ^ v
vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings()
| ^ v
dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings()

The dummy device is ops locked, vlan creates a nested event (2), then bond wants to ask vlan for link state (3). bond uses the "I'm already holding the instance lock" flavor of API. But in this case the lock held refers to vlan itself. We hit vlan's link settings trampoline (4) and call __ethtool_get_link_ksettings() which tries to lock dummy. Deadlock. There's no clean way for us to tell the vlan_ethtool_get_link_ksettings() that the caller is already in lower device's critical section.

Defer the propagation to the per-netdev work facility instead:
the notifier only schedules netdev_work_sched(vlandev, VLAN_WORK_*), and ndo_work (vlan_dev_work) applies the change later. Hopefully nobody expects the VLAN state changes to be instantaneous.

If someone does expect the changes to be instantaneous we will have to do the same thing Stan did for rx_mode and "strategically" place sync calls, to make sure such delayed works are executed after we drop the ops lock but before we drop rtnl_lock.

Stan suggests that if we need that down the line we may consider reshaping the mechanism into "async notifications". AFAICT only vlan does this sort of netdev open chaining, so as a first try I think that sticking the complexity into the vlan code makes sense.

One corner case is that we need to cancel the event if user explicitly changes the state before work could run. Consider the following operations with vlan0 on top of dummy0:

  ip link set dev dummy0 up    # queues work to up vlan0
  ip link set dev vlan0 down   # user explicitly downs the vlan
  ndo_work                     # acts on the stale event

Reported-by [email protected]

Reported-by [email protected]

Reported-by [email protected]

Fixes 9f275c2e9020 ("net: ethtool: make sure __ethtool_get_link_ksettings() is ops-locked")

Signed-off-by Jakub Kicinski <[email protected]>

vlan_device_event() generates nested UP/DOWN, MTU and feature change events. It executes an event for the VLAN device directly from the notifier - while the locks of the lower device are held.

This causes deadlocks, for example:

bond (3) bond_update_speed_duplex(vlan)
| ^ v
vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings()
| ^ v
dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings()

The dummy device is ops locked, vlan creates a nested event (2), then bond wants to ask vlan for link state (3). bond uses the "I'm already holding the instance lock" flavor of API. But in this case the lock held refers to vlan itself. We hit vlan's link settings trampoline (4) and call __ethtool_get_link_ksettings() which tries to lock dummy. Deadlock. There's no clean way for us to tell the vlan_ethtool_get_link_ksettings() that the caller is already in lower device's critical section.

Defer the propagation to the per-netdev work facility instead:
the notifier only schedules netdev_work_sched(vlandev, VLAN_WORK_*), and ndo_work (vlan_dev_work) applies the change later. Hopefully nobody expects the VLAN state changes to be instantaneous.

If someone does expect the changes to be instantaneous we will have to do the same thing Stan did for rx_mode and "strategically" place sync calls, to make sure such delayed works are executed after we drop the ops lock but before we drop rtnl_lock.

Stan suggests that if we need that down the line we may consider reshaping the mechanism into "async notifications". AFAICT only vlan does this sort of netdev open chaining, so as a first try I think that sticking the complexity into the vlan code makes sense.

One corner case is that we need to cancel the event if user explicitly changes the state before work could run. Consider the following operations with vlan0 on top of dummy0:

  ip link set dev dummy0 up    # queues work to up vlan0
  ip link set dev vlan0 down   # user explicitly downs the vlan
  ndo_work                     # acts on the stale event

Reported-by [email protected]

Reported-by [email protected]

Reported-by [email protected]

Fixes 9f275c2e9020 ("net: ethtool: make sure __ethtool_get_link_ksettings() is ops-locked")

Signed-off-by Jakub Kicinski <[email protected]>

---

[...]

vlan_device_event() generates nested UP/DOWN, MTU and feature change events. It executes an event for the VLAN device directly from the notifier - while the locks of the lower device are held.

This causes deadlocks, for example:

bond (3) bond_update_speed_duplex(vlan)
| ^ v
vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings()
| ^ v
dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings()

The dummy device is ops locked, vlan creates a nested event (2), then bond wants to ask vlan for link state (3). bond uses the "I'm already holding the instance lock" flavor of API. But in this case the lock held refers to vlan itself. We hit vlan's link settings trampoline (4) and call __ethtool_get_link_ksettings() which tries to lock dummy. Deadlock. There's no clean way for us to tell the vlan_ethtool_get_link_ksettings() that the caller is already in lower device's critical section.

Defer the propagation to the per-netdev work facility instead:
the notifier only schedules netdev_work_sched(vlandev, VLAN_WORK_*), and ndo_work (vlan_dev_work) applies the change later. Hopefully nobody expects the VLAN state changes to be instantaneous.

If someone does expect the changes to be instantaneous we will have to do the same thing Stan did for rx_mode and "strategically" place sync calls, to make sure such delayed works are executed after we drop the ops lock but before we drop rtnl_lock.

Stan suggests that if we need that down the line we may consider reshaping the mechanism into "async notifications". AFAICT only vlan does this sort of netdev open chaining, so as a first try I think that sticking the complexity into the vlan code makes sense.

One corner case is that we need to cancel the event if user explicitly changes the state before work could run. Consider the following operations with vlan0 on top of dummy0:

  ip link set dev dummy0 up    # queues work to up vlan0
  ip link set dev vlan0 down   # user explicitly downs the vlan
  ndo_work                     # acts on the stale event

Reported-by [email protected]

Reported-by [email protected]

Reported-by [email protected]

Fixes 9f275c2e9020 ("net: ethtool: make sure __ethtool_get_link_ksettings() is ops-locked")

Signed-off-by Jakub Kicinski <[email protected]>

-----Original Message-----
From: Jakub Kicinski <[email protected]>
Sent: Wednesday, June 24, 2026 8:20 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; nb@tipi- net.de; Loktionov, Aleksandr <[email protected]>; [email protected]; Jakub Kicinski <[email protected]>
Subject: [PATCH net 4/4] selftests: bonding: add a test for VLAN propagation over a bonded real device

Add a regression test for the VLAN notifier handling that the netdev_work deferral fixed.

A VLAN's real device propagates its UP/DOWN, MTU and feature changes onto the VLANs stacked on top of it. This used to be done synchronously from the real device's notifier and deadlocked when the real device was brought up while enslaved to a bond (instance lock held across NETDEV_UP) and the VLAN on top was itself a bond member:
the synchronous propagation re-entered the stack and took the same instance lock again.

The test covers both halves:
- that the deferred UP/DOWN, MTU and feature propagation actually
lands on
the VLAN (link state and MTU use an ops-locked dummy, i.e. the
deferral
path; features use veth, which exports vlan_features to inherit),
and
- that the deadlock-prone topology - a VLAN on a dummy, with the VLAN
and
the dummy each enslaved to a different bond - can be built without hanging.

Signed-off-by Jakub Kicinski <[email protected]>

---
 .../selftests/drivers/net/bonding/Makefile    |   1 +
 .../drivers/net/bonding/bond_vlan_real_dev.sh | 180
++++++++++++++++++
 2 files changed, 181 insertions(+)
 create mode 100755

tools/testing/selftests/drivers/net/bonding/bond_vlan_real_dev.sh

tools/testing/selftests/drivers/net/bonding/Makefile +1 -0

index be130bf585a4..6364ca02642d 100644
@@ -13,6 +13,7 @@ TEST_PROGS := \
 	bond_options.sh \
 	bond_passive_lacp.sh \
 	bond_stacked_header_parse.sh \
+	bond_vlan_real_dev.sh \
 	dev_addr_lists.sh \
 	mode-1-recovery-updelay.sh \
 	mode-2-recovery-updelay.sh \

diff --git a/tools/testing/selftests/drivers/net/bonding/bond_vlan_real_dev.sh b/tools/testing/selftests/drivers/net/bonding/bond_vlan_real_dev.sh new file mode 100755
index 000000000000..542d9ffc4819
--- /dev/null
+++
b/tools/testing/selftests/drivers/net/bonding/bond_vlan_real_dev.sh

tools/testing/selftests/drivers/net/bonding/Makefile +0 -0

@@ -0,0 +1,180 @@

+exit "$EXIT_STATUS"
--
2.54.0

Add a regression test for the VLAN notifier handling that the netdev_work deferral fixed.

A VLAN's real device propagates its UP/DOWN, MTU and feature changes onto the VLANs stacked on top of it. This used to be done synchronously from the real device's notifier and deadlocked when the real device was brought up while enslaved to a bond (instance lock held across NETDEV_UP) and the VLAN on top was itself a bond member: the synchronous propagation re-entered the stack and took the same instance lock again.

The test covers both halves:
- that the deferred UP/DOWN, MTU and feature propagation actually lands on the VLAN (link state and MTU use an ops-locked dummy, i.e. the deferral path; features use veth, which exports vlan_features to inherit), and
- that the deadlock-prone topology - a VLAN on a dummy, with the VLAN and the dummy each enslaved to a different bond - can be built without hanging.

Signed-off-by Jakub Kicinski <[email protected]>