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

[Paolo Abeni <pabeni@redhat.com>]

On 9/10/26 3:22 AM, Jakub Kicinski wrote:
> 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.

I see. I suspect containers orchestration/control-plane heavy
application could notice if they depends on the relevant handlers (I
think at least the one I'm less unfamiliar with doesn't) when the
relevant change will reach downstream.

I think we can improve incrementally as need (at least here should be
quite straight-forward, for gennetlink dump handlers it looks more complex).

/P