On 13/09/21 11:11 pm, Bart Van Assche wrote: > On 9/13/21 10:13 AM, Adrian Hunter wrote: >> SCSI_MLQUEUE_HOST_BUSY causes scsi_host_busy() to decrement by calling >> scsi_dec_host_busy() as described above, so the request is not being >> counted in that condition anymore. > > Let's take a step back. My understanding is that the deadlock is caused by > the combination of: > * SCSI command processing being blocked because of the state > UFSHCD_STATE_EH_SCHEDULED_FATAL. That assumes "scsi: ufs: Synchronize SCSI and UFS error handling" is reverted. With "scsi: ufs: Synchronize SCSI and UFS error handling" all requests are blocked because scsi_host_in_recovery(). > * The sdev_ufs_device and/or sdev_rpmb request queues are frozen > (blk_mq_freeze_queue() has started). Yes > * A REQUEST SENSE command being scheduled from inside the error handler > (ufshcd_clear_ua_wlun()). Not exactly. It is not possible to enter the queue after freezing starts so blk_queue_enter() is stuck waiting on any existing requests to exit the queue, but existing requests are blocked as described above. > > Is this a theoretical concern or something that has been observed on a test > setup? It is observed on Samsung Galaxy Book S when suspending. > > If this has been observed on a test setup, was the error handler scheduled > (ufshcd_err_handler())? Yes. > > I don't see how SCSI command processing could get stuck indefinitely since > it is guaranteed that the UFS error handler will get scheduled and also that > the UFS error handler will change ufshcd_state from > UFSHCD_STATE_EH_SCHEDULED_FATAL into another state? The error handler is stuck waiting on the freeze, which is stuck waiting on requests which are stuck waiting on the error handler. > > What am I missing? You have not responded to the issues raised by "scsi: ufs: Synchronize SCSI and UFS error handling"
