[PATCH net 3/3] iavf: drop netdev lock while waiting for MAC change completion

[PATCH net 3/3] iavf: drop netdev lock while waiting for MAC change completion

[Jose Ignacio Tornos Martinez]

After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs
operations"), iavf_set_mac() is called with the netdev instance lock
already held.

The function queues a MAC address change request and then waits for
completion while holding this lock. However, the watchdog task that
processes admin queue commands (including MAC changes) also needs to
acquire the netdev lock to run.

This creates a lock contention scenario:
1. iavf_set_mac() holds netdev lock and waits for MAC change
2. Watchdog needs netdev lock to process the MAC change request
3. Watchdog blocks waiting for lock
4. MAC change times out after 2.5 seconds
5. iavf_set_mac() returns -EAGAIN

This particularly affects VFs during initialization when enslaved to a
bond. The first VF typically succeeds as it's already fully initialized,
but subsequent VFs fail as they're still progressing through their state
machine and need the watchdog to advance.

Fix by temporarily dropping the netdev lock before waiting for MAC change
completion, allowing the watchdog to run and process the request, then
re-acquiring the lock before returning.

This is safe because:
- The MAC change request is already queued before we drop the lock
- iavf_is_mac_set_handled() just checks filter state, doesn't modify it
- We re-acquire the lock before checking results and returning

Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations")
cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
 drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index dad001abc908..6281858e6f3c 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1068,10 +1068,14 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
 	if (ret)
 		return ret;
 
+	netdev_unlock(netdev);
+
 	ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
 					       iavf_is_mac_set_handled(netdev, addr->sa_data),
 					       msecs_to_jiffies(2500));
 
+	netdev_lock(netdev);
+
 	/* If ret < 0 then it means wait was interrupted.
 	 * If ret == 0 then it means we got a timeout.
 	 * else it means we got response for set MAC from PF,
-- 
2.53.0

Re: [PATCH net 3/3] iavf: drop netdev lock while waiting for MAC change completion

[Kohei Enju]

On 04/06 13:20, Jose Ignacio Tornos Martinez wrote:
> After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs
> operations"), iavf_set_mac() is called with the netdev instance lock
> already held.
> 
> The function queues a MAC address change request and then waits for
> completion while holding this lock. However, the watchdog task that
> processes admin queue commands (including MAC changes) also needs to
> acquire the netdev lock to run.
> 
> This creates a lock contention scenario:
> 1. iavf_set_mac() holds netdev lock and waits for MAC change
> 2. Watchdog needs netdev lock to process the MAC change request
> 3. Watchdog blocks waiting for lock
> 4. MAC change times out after 2.5 seconds
> 5. iavf_set_mac() returns -EAGAIN
> 
> This particularly affects VFs during initialization when enslaved to a
> bond. The first VF typically succeeds as it's already fully initialized,
> but subsequent VFs fail as they're still progressing through their state
> machine and need the watchdog to advance.
> 
> Fix by temporarily dropping the netdev lock before waiting for MAC change
> completion, allowing the watchdog to run and process the request, then
> re-acquiring the lock before returning.
> 
> This is safe because:
> - The MAC change request is already queued before we drop the lock
> - iavf_is_mac_set_handled() just checks filter state, doesn't modify it
> - We re-acquire the lock before checking results and returning
> 
> Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations")
> cc: stable@vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
>  drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index dad001abc908..6281858e6f3c 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> @@ -1068,10 +1068,14 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
>  	if (ret)
>  		return ret;
>  
> +	netdev_unlock(netdev);
> +
>  	ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
>  					       iavf_is_mac_set_handled(netdev, addr->sa_data),
>  					       msecs_to_jiffies(2500));
>  
> +	netdev_lock(netdev);
> +

Hi Jose, thank you for the fix and detailed explanation.

I don't have a great solution for this issue, but dropping the netdev
lock taken by the networking core in the driver callback might not look
acceptable.

FYI, Petr reported the same type of locking issue in
ndo_change_mtu(), and the v1 approach was really similar to this one.
https://lore.kernel.org/intel-wired-lan/20260202155813.3f8fbc27@kernel.org/

IIUC, the issue was eventually fixed by completing the reset
synchronously in the same context as ndo_change_mtu(), instead of
dropping the netdev lock and waiting for reset_task.
https://lore.kernel.org/intel-wired-lan/20260211191855.1532226-1-poros@redhat.com/

If that applies here as well, maybe iavf_set_mac() needs a similar
approach, e.g. progressing the relevant virtchnl request/completion
synchronously with the netdev lock held, rather than dropping the lock
here?

>  	/* If ret < 0 then it means wait was interrupted.
>  	 * If ret == 0 then it means we got a timeout.
>  	 * else it means we got response for set MAC from PF,
> -- 
> 2.53.0
> 

Re: [PATCH net 3/3] iavf: drop netdev lock while waiting for MAC change completion

[Jose Ignacio Tornos Martinez]

Hi Kohei,

Thank you for your help and reference.
I will try to do it synchronously with the netdev lock held as you say.

Best regards
Jose Ignacio