If firmware probing worker failed it called
device_release_driver() which synchronously called
remove() pci callback. The callback in turn waited
for the worker that called it to finish resulting
in a deadlock.
Waiting for a completion instead of a worker, like
some other drivers do, doesn't seem like the best
idea either:
Syscall Worker
probe_fw()
rmmod
dev_lock()
pci->remove()
wait_for_completion()
complete_all()
device_release_driver()
dev_lock()
[sleep]
free(ar)
dev_unlock()
[resume]
There's no guarantee that Worker upon resuming can
still access any data/code of the module.
Leaving device bound to a driver is not as harmful
as deadlocking so remove the call to
device_release_driver() while a proper solution is
figured out.
Signed-off-by: Michal Kazior <[email protected]>
---
drivers/net/wireless/ath/ath10k/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 82017f5..b70e443 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -984,7 +984,9 @@ err_unregister_mac:
err_release_fw:
ath10k_core_free_firmware_files(ar);
err:
- device_release_driver(ar->dev);
+ /* TODO: It's probably a good idea to release device from the driver
+ * but calling device_release_driver() here will cause a deadlock.
+ */
return;
}
--
1.8.5.3
Michal Kazior <[email protected]> writes:
> If firmware probing worker failed it called
> device_release_driver() which synchronously called
> remove() pci callback. The callback in turn waited
> for the worker that called it to finish resulting
> in a deadlock.
>
> Waiting for a completion instead of a worker, like
> some other drivers do, doesn't seem like the best
> idea either:
>
> Syscall Worker
>
> probe_fw()
> rmmod
> dev_lock()
> pci->remove()
> wait_for_completion()
> complete_all()
> device_release_driver()
> dev_lock()
> [sleep]
> free(ar)
> dev_unlock()
> [resume]
>
> There's no guarantee that Worker upon resuming can
> still access any data/code of the module.
>
> Leaving device bound to a driver is not as harmful
> as deadlocking so remove the call to
> device_release_driver() while a proper solution is
> figured out.
>
> Signed-off-by: Michal Kazior <[email protected]>
Thanks, applied.
--
Kalle Valo