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.
