Re: [net-next,3/5] ice: migrate to netdev ops lock

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Jakub Kicinski <kuba@kernel.org>
Date: Mon, 16 Mar 2026 16:16:30 -0700

> On Mon, 16 Mar 2026 16:10:49 +0100 Alexander Lobakin wrote:
>>> Does ice_dcb_ena_dis_vsi() need to acquire the netdev lock before calling
>>> ice_dis_vsi_locked() and ice_ena_vsi()?
>>>
>>> Looking at the disable path, ice_dis_vsi_locked() calls ice_vsi_close()
>>> which goes through ice_down() -> ice_napi_disable_all() ->
>>> napi_disable_locked(), and that function has netdev_assert_locked(n->dev) in
>>> net/core/dev.c. Similarly, ice_vsi_close() calls
>>> ice_vsi_clear_napi_queues_locked() -> netif_napi_set_irq_locked() which
>>> checks netdev_assert_locked_or_invisible().
>>>
>>> The enable path calls ice_ena_vsi() -> ice_open_internal() ->
>>> ice_vsi_open(), and that now calls ice_vsi_set_napi_queues_locked() ->
>>> netif_napi_set_irq_locked() (requires netdev lock) and ice_up_complete() ->
>>> ice_napi_enable_all() -> napi_enable_locked().
>>>
>>> The old code called ice_dis_vsi(vsi, locked) and ice_ena_vsi(vsi, locked)
>>> where the old ice_dis_vsi() only dealt with rtnl_lock. The new code switches
>>> to _locked variants that require the netdev lock but does not acquire it.
>>>
>>> Callers ice_pf_dcb_cfg() and ice_dcb_process_lldp_set_mib_change() hold
>>> rtnl_lock but not the netdev lock.  
>>
>> Doesn't the DCB core take the netdev lock just like netdev_ops? Or it
>> only takes the RTNL?
> 
> DCB is not covered by the instance lock.. but TBH purely because 
> I just always forget it exists. Feel free to make it take the lock
> if that makes more sense.

I'd leave as it is for this series to not increase the diffstat and room
for probably bugs (as other drivers would need adjustments in that
case). So I'll make ice to take the lock in its DCB code for now.

BTW, if it's not top secret, how do you run these AI reviews? Because
Tony used the same link as these reports provide to deploy a setup, but
we didn't manage to get as meaningful results as yours. That's why
several respins of this series only due to your AI reviews, sorry =\

Thanks,
Olek