This is a note to let you know that I've just added the patch titled
mwifiex: resolve reset vs. remove()/shutdown() deadlocks
to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: mwifiex-resolve-reset-vs.-remove-shutdown-deadlocks.patch and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From a64e7a79dd6030479caad603c8d78e6c9c14904f Mon Sep 17 00:00:00 2001
From: Brian Norris briannorris@chromium.org Date: Fri, 12 Jan 2018 13:08:37 -0800 Subject: mwifiex: resolve reset vs. remove()/shutdown() deadlocks
From: Brian Norris briannorris@chromium.org
commit a64e7a79dd6030479caad603c8d78e6c9c14904f upstream.
Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") resolves races between driver reset and removal, but it introduces some new deadlock problems. If we see a timeout while we've already started suspending, removing, or shutting down the driver, we might see:
(a) a worker thread, running mwifiex_pcie_work() -> mwifiex_pcie_card_reset_work() -> pci_reset_function() (b) a removal thread, running mwifiex_pcie_remove() -> mwifiex_free_adapter() -> mwifiex_unregister() -> mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work)
Unfortunately, mwifiex_pcie_remove() already holds the device lock that pci_reset_function() is now requesting, and so we see a deadlock.
It's necessary to cancel and synchronize our outstanding work before tearing down the driver, so we can't have this work wait indefinitely for the lock.
It's reasonable to only "try" to reset here, since this will mostly happen for cases where it's already difficult to reset the firmware anyway (e.g., while we're suspending or powering off the system). And if reset *really* needs to happen, we can always try again later.
Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: stable@vger.kernel.org Cc: Xinming Hu huxm@marvell.com Signed-off-by: Brian Norris briannorris@chromium.org Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -2781,7 +2781,10 @@ static void mwifiex_pcie_card_reset_work { struct pcie_service_card *card = adapter->card;
- pci_reset_function(card->dev); + /* We can't afford to wait here; remove() might be waiting on us. If we + * can't grab the device lock, maybe we'll get another chance later. + */ + pci_try_reset_function(card->dev); }
static void mwifiex_pcie_work(struct work_struct *work)
Patches currently in stable-queue which might be from briannorris@chromium.org are
queue-4.14/mwifiex-resolve-reset-vs.-remove-shutdown-deadlocks.patch