On 13/09/21 11:11 pm, Bart Van Assche wrote:

On 9/13/21 10:13 AM, Adrian Hunter wrote:

quoted

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"