On 1/09/21 11:46 pm, Bart Van Assche wrote: > 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? UFS Device WLUN aka UFS Device Well-known LUN aka LUN 49488. It is in the spec. > > 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. __ufshcd_wl_suspend() and __ufshcd_wl_resume() are for the UFS Device WLUN (what the wl stands for). All other LUNs are device link consumers of it. > > 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. A detailed example was provided.
