summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/microchip
diff options
context:
space:
mode:
authorMichal Schmidt <mschmidt@redhat.com>2022-12-16 01:50:48 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-02-01 10:34:42 +0300
commitaa17cf8af776279f92d876dc2c80ff67468f73c8 (patch)
tree6f9bac4b7e0e7d3b6c08a4bb4348c03f42da0d06 /drivers/net/ethernet/microchip
parent0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb (diff)
downloadlinux-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