On 9/3/21 2:56 AM, Adrian Hunter wrote:

There is no guarantee to be able to enter the queue if requests are
blocked. That is because freezing the queue will block entry to the
queue, but freezing also waits for outstanding requests which can make
no progress while the queue is blocked.

That situation can happen when the error handler issues requests to
clear unit attention condition. The deadlock is very unlikely, so the
error handler can be expected to clear ua at some point anyway, so the
simple solution is not to wait to enter the queue.

Additionally, note that the RPMB queue might be not be entered because
it is runtime suspended, but in that case ua will be cleared at RPMB
runtime resume.

The only ufshcd_clear_ua_wluns() call that I am aware of and that is 
related to error handling is the call in 
ufshcd_err_handling_unprepare(). That call happens after 
ufshcd_scsi_unblock_requests() has been called so how can it be involved 
in a deadlock?

Additionally, the ufshcd_scsi_block_requests() and 
ufshcd_scsi_unblock_requests() calls can be removed from 
ufshcd_err_handling_prepare() and ufshcd_err_handling_unprepare(). These 
calls are no longer necessary since patch "scsi: ufs: Synchronize SCSI 
and UFS error handling".

Thanks,

Bart.