On 28/08/21 12:47 pm, Adrian Hunter wrote: > On 22/07/21 6:34 am, Bart Van Assche wrote: >> Use the SCSI error handler instead of a custom error handling strategy. >> This change reduces the number of potential races in the UFS drivers since >> the UFS error handler and the SCSI error handler no longer run concurrently. >> >> Cc: Adrian Hunter <adrian.hunter@xxxxxxxxx> >> Cc: Stanley Chu <stanley.chu@xxxxxxxxxxxx> >> Cc: Can Guo <cang@xxxxxxxxxxxxxx> >> Cc: Asutosh Das <asutoshd@xxxxxxxxxxxxxx> >> Cc: Avri Altman <avri.altman@xxxxxxx> >> Signed-off-by: Bart Van Assche <bvanassche@xxxxxxx> >> --- > > Hi > > There is a deadlock that seems to be related to this patch, because now > requests are blocked while the error handler waits on the host_sem. > > > Example: > > ufshcd_err_handler() races with ufshcd_wl_suspend() for host_sem. > ufshcd_wl_suspend() wins the race but now PM requests deadlock: > > because: > scsi_queue_rq() -> scsi_host_queue_ready() -> scsi_host_in_recovery() is FALSE That is scsi_host_queue_ready() is FALSE because scsi_host_in_recovery() is TRUE > > because: > scsi_schedule_eh() has done: > scsi_host_set_state(shost, SHOST_RECOVERY) == 0 || > scsi_host_set_state(shost, SHOST_CANCEL_RECOVERY) == 0) > > > Some questions for thought: > > Won't any holder of host_sem deadlock if it tries to do SCSI requests > and the error handler is waiting on host_sem? > > Won't runtime resume deadlock if it is initiated by the error handler? > > > Regards > Adrian >
