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

From: Adrian Hunter <adrian.hunter@intel.com>
To: Bart Van Assche <bvanassche@acm.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>,
	Bean Huo <huobean@gmail.com>, Avri Altman <avri.altman@wdc.com>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Can Guo <cang@codeaurora.org>,
	Asutosh Das <asutoshd@codeaurora.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Wei Li <liwei213@huawei.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH V3 1/3] scsi: ufs: Fix error handler clear ua deadlock
Date: Tue, 14 Sep 2021 07:55:45 +0300	[thread overview]
Message-ID: <8b3f4f40-4959-17ee-577e-ab9473e4882b@intel.com> (raw)
In-Reply-To: <2a43c750-ec15-2ac9-b899-00ed911addd8@acm.org>

On 13/09/21 11:11 pm, Bart Van Assche wrote:
> 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.

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"