On 9/19/22 10:21, Adrian Hunter wrote:
I guess it goes unnoticed because it is very unlikely i.e. the UFS
device would need to be suspending but not yet have claimed host_sem.
There would not be any outstanding requests otherwise the suspend
would not have started, so chance of errors at that point is very low.
Maybe deadlock could be sidestepped by changing:
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 7256e6c43ca6..9cb04c6f8dc3 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -9258,7 +9261,10 @@ static int ufshcd_wl_suspend(struct device *dev)
ktime_t start = ktime_get();
hba = shost_priv(sdev->host);
- down(&hba->host_sem);
+ if (down_trylock(&hba->host_sem)) {
+ ret = -EBUSY;
+ goto out;
+ }
if (pm_runtime_suspended(dev))
goto out;
Hi Adrian,
Unfortunately I don't think that the above change would help. My
conclusion from the logs that I analyzed is that ufshcd_wl_suspend() is
called first and also that the error handler is invoked while
ufshcd_wl_suspend() holds host_sem, resulting in a deadlock.
Thanks,
Bart.
