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 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
