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.