Re: [PATCH net-next] net: opt loopback into instance locking

[Wang Zhan <wang.zhan@smartx.com>]

On Mon, 09 Nov 2026 09:39:02 -0800 Jakub Kicinski wrote:
> netdev netlink iterates over devices when dumping queues/NAPIs/qstats
> etc. and takes rtnl_lock or instance lock depending on the underlying
> device. Currently even if all the "real" devices in the system are ops
> locked we still have to take rtnl_lock for lo (only to find out
> that it doesn't even have queues or NAPIs to report).
> Opt loopback into having control path under the ops lock.

nit: NAPI dump no longer takes RTNL since commit
062e789172226 ("netdev-genl: remove rtnl_lock protection from NAPI
ops"). "dumping queues/qstats" is enough, right?

> This is a pretty obvious thing to do, I've held back this
> patch because we used to only apply ops locking on physical devices.
> netkit queue leasing made a precedent for (far more complex)
> SW devices enabling ops locking. Now adding it to lo should
> not create much new bug surface.
>
> I considered an alternative of adding a "predicate" to the iteration
> primitive so that we can skip the devices which obviously don't
> support given API (eg qstat) without any locking. But it's more
> LoC and real_num_.x_queues is not currently WRITE_ONCE()ed so
> it doesn't work too well for queues.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Tested on x86_64 QEMU TCG with lockdep:
- with RTNL held for 3 seconds, all-device queue and qstats dumps waited
  before this patch and completed in about 4 ms after it
- no lockdep warnings across lo up/down, MTU change, rename,
  promisc/allmulti, ethtool get_link/get_ts_info and netns teardown

Tested-by: Wang Zhan <wang.zhan@smartx.com>

Thanks