Re: [PATCH net-next] net: run netdev work under the ops-compat lock

[Jakub Kicinski <kuba@kernel.org>]

Oops, looks like this has been sitting in my outbox for some reason

On Tue, 8 Sep 2026 13:26:52 +0200 Paolo Abeni wrote:
> On 9/4/26 8:00 PM, Jakub Kicinski wrote:
> > netdev_work_proc() took rtnl_lock() for the whole batch, forcing
> > even ops-locked drivers onto rtnl just to run their rx_mode / ndo_work
> > callbacks. Take the per-device ops-compat lock instead: the instance
> > lock for ops-locked drivers, rtnl_lock for the rest. That's what the
> > callbacks already assert (e.g. netif_rx_mode_run() asserts
> > netdev_assert_locked_ops_compat()), and non-ops-locked work
> > such as vlan ndo_work keeps rtnl, since its compat lock resolves
> > to rtnl anyway.
> > 
> > Without this adding more uses of ndo_work, for cases which don't
> > need rtnl_lock feels like a step back.
> > 
> > We can drop the comment about the extra ref now, with the relocking
> > it's a necessity.
> > 
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>  
> Dump question: can the `netdev_work_list` work list grow significantly
> under non pathological conditions? netdev_work_proc is now going to
> acquire and release the rtnl lock n-times for non ops-enabled drivers.
> 
> Would it be overkill trying to acquire the rtnl lock at most once (i.e.
> keeping the netdev_need_ops_lock() and legacy drivers on separate list
> and process them accordingly?)

I haven't seen any evidence of such relocking causing issues so I didn't
want to complicate the code. We have a similar situation in a number of
netdev genetlink dump handlers.