Re: [PATCH V3 1/3] scsi: ufs: Fix error handler clear ua deadlock

[Adrian Hunter <adrian.hunter@intel.com>]

On 7/09/21 5:42 pm, Bart Van Assche wrote:
> On 9/5/21 2:51 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. Requests can be blocked if the
>> ufshcd_state is UFSHCD_STATE_EH_SCHEDULED_FATAL, which can happen
>> as a result either of error handler activity, or theoretically a
>> request that is issued after the error handler unblocks the queue
>> but before clearing 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.
> 
> Do you agree that the interaction between ufshcd_scsi_block_requests() and
> blk_mq_freeze_queue() can only lead to a deadlock if blk_queue_enter() is
> called without using the BLK_MQ_REQ_NOWAIT flag and if unblocking SCSI
> request processing can only happen by the same thread?

Sure

> Do you agree that no ufshcd_clear_ua_wluns() caller blocks SCSI request
> processing and hence that it is not necessary to add a "nowait" argument
> to ufshcd_clear_ua_wluns()?

No.  Requests cannot make progress when ufshcd_state is
UFSHCD_STATE_EH_SCHEDULED_FATAL, and only the error handler can change that,
so if the error handler is waiting to enter the queue and blk_mq_freeze_queue()
is waiting for outstanding requests, they will deadlock.