Re: [PATCH net-next v2 05/11] net: bonding: don't recurse on the slave's netdev ops lock

Hi Jakub

On 3.6.2026 03:28, Jakub Kicinski wrote:

bond_update_speed_duplex() calls __ethtool_get_link_ksettings() on
the slave, which will soon take the slave's ops lock. One of its
callers already holds it and the other three don't, so the function
would either deadlock or run unprotected depending on the path.

Make the helper expect the slave's ops lock held and switch to
netif_get_link_ksettings(). Wrap the three call sites that don't
already hold it:

  * bond_enslave() (rtnl held; core drops the lower's ops lock
    around ->ndo_add_slave).
  * bond_miimon_commit() (rtnl_trylock'd from the mii workqueue).
  * bond_ethtool_get_link_ksettings() (rtnl held via ethtool layer,
    bond device itself is not ops locked).

The call site which does already hold the ops lock is
bond_slave_netdev_event() via NETDEV_UP / NETDEV_CHANGE notifiers,
so it stays as-is.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>

[...]

Reviewed-by: Nicolai Buchwitz <redacted>

Thanks
Nicolai