From: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
Date: Wed, 12 Mar 2025 18:16:11 +0100
> From: Eric Dumazet <edumazet@xxxxxxxxxx>
> Date: Fri, 7 Mar 2025 11:28:36 +0100
>
>> On Wed, Mar 5, 2025 at 5:22 PM Alexander Lobakin
>> <aleksander.lobakin@xxxxxxxxx> wrote:
>>>
>>> Add the missing linking of NAPIs to netdev queues when enabling
>>> interrupt vectors in order to support NAPI configuration and
>>> interfaces requiring get_rx_queue()->napi to be set (like XSk
>>> busy polling).
>>>
>>> Signed-off-by: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
>>> ---
>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 30 +++++++++++++++++++++
>>> 1 file changed, 30 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>> index 2f221c0abad8..a3f6e8cff7a0 100644
>>> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>> @@ -3560,8 +3560,11 @@ void idpf_vport_intr_rel(struct idpf_vport *vport)
>>> static void idpf_vport_intr_rel_irq(struct idpf_vport *vport)
>>> {
>>> struct idpf_adapter *adapter = vport->adapter;
>>> + bool unlock;
>>> int vector;
>>>
>>> + unlock = rtnl_trylock();
>>
>> This is probably not what you want here ?
>>
>> If another thread is holding RTNL, then rtnl_ttrylock() will not add
>> any protection.
>
> Yep I know. trylock() is because this function can be called in two
> scenarios:
>
> 1) .ndo_close(), when RTNL is already locked;
> 2) "soft reset" aka "stop the traffic, reallocate the queues, start the
> traffic", when RTNL is not taken.
>
> The second one spits a WARN without the RTNL being locked. So this
> trylock() will do nothing for the first scenario and will take the lock
> for the second one.
>
> If that is not correct, let me know, I'll do it a different way (maybe
> it's better to unconditionally take the lock on the callsite for the
> second case?).
Ping. What should I do, lock RTNL on the callsite or proceed with trylock?
Thanks,
Olek
