On 9/1/21 12:42 AM, Adrian Hunter wrote:
No it doesn't use host_sem. The problem is with issuing requests to a blocked queue. If the UFS device is in SLEEP state, runtime resume will try to do a SCSI request to change to ACTIVE state. That will block while the error handler is running. So if the error handler is waiting on runtime resume, deadlock.
Please define "UFS device". Does this refer to the physical device or to a LUN?
I agree that suspending or resuming a LUN involves executing a SCSI command. See also __ufshcd_wl_suspend() and __ufshcd_wl_resume(). These functions are used to suspend or resume a LUN and not to suspend or resume the UFS device.
However, I don't see how the above scenario would lead to a deadlock? The UFS error handler (ufshcd_err_handler()) works at the link level and may resume the SCSI host and/or UFS device (hba->host and hba->dev). The UFS error handler must not try to resume any of the LUNs since that involves executing SCSI commands.
Bart.
