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. * The sdev_ufs_device and/or sdev_rpmb request queues are frozen (blk_mq_freeze_queue() has started). * A REQUEST SENSE command being scheduled from inside the error handler (ufshcd_clear_ua_wlun()). Is this a theoretical concern or something that has been observed on a test setup? If this has been observed on a test setup, was the error handler scheduled (ufshcd_err_handler())? 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? What am I missing? Thanks, Bart.
