diff options
author | Michal Schmidt <mschmidt@redhat.com> | 2022-12-16 01:50:48 +0300 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2023-02-01 10:34:42 +0300 |
commit | aa17cf8af776279f92d876dc2c80ff67468f73c8 (patch) | |
tree | 6f9bac4b7e0e7d3b6c08a4bb4348c03f42da0d06 /drivers/net/ethernet/microchip | |
parent | 0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb (diff) | |
download | linux-aa17cf8af776279f92d876dc2c80ff67468f73c8.tar.xz |
iavf: fix temporary deadlock and failure to set MAC address
[ Upstream commit 4411a608f7c8df000cb1a9f7881982dd8e10839a ]
We are seeing an issue where setting the MAC address on iavf fails with
EAGAIN after the 2.5s timeout expires in iavf_set_mac().
There is the following deadlock scenario:
iavf_set_mac(), holding rtnl_lock, waits on:
iavf_watchdog_task (within iavf_wq) to send a message to the PF,
and
iavf_adminq_task (within iavf_wq) to receive a response from the PF.
In this adapter state (>=__IAVF_DOWN), these tasks do not need to take
rtnl_lock, but iavf_wq is a global single-threaded workqueue, so they
may get stuck waiting for another adapter's iavf_watchdog_task to run
iavf_init_config_adapter(), which does take rtnl_lock.
The deadlock resolves itself by the timeout in iavf_set_mac(),
which results in EAGAIN returned to userspace.
Let's break the deadlock loop by changing iavf_wq into a per-adapter
workqueue, so that one adapter's tasks are not blocked by another's.
Fixes: 35a2443d0910 ("iavf: Add waiting for response from PF in set mac")
Co-developed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/net/ethernet/microchip')
0 files changed, 0 insertions, 0 deletions