[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d66b6d0-26c6-573f-e2a0-022e22c47b52@acm.org>
Date: Thu, 28 Oct 2021 08:59:25 -0700
From: Bart Van Assche <bvanassche@....org>
To: jejb@...ux.ibm.com, daejun7.park@...sung.com,
ALIM AKHTAR <alim.akhtar@...sung.com>,
"avri.altman@....com" <avri.altman@....com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"huobean@...il.com" <huobean@...il.com>,
Keoseong Park <keosung.park@...sung.com>
Cc: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] scsi: ufs: Fix proper API to send HPB pre-request
On 10/28/21 7:28 AM, James Bottomley wrote:
> If the block people are happy with this, then I'm OK with it, but it
> doesn't look like you've solved the fanout deadlock problem because
> this new mechanism is still going to allocate a new tag.
(+Jens, Christoph and linux-block)
Hi James,
My understanding is that the UFS HPB code makes ufshcd_queuecommand()
return SCSI_MLQUEUE_HOST_BUSY if the pool with pre-allocated requests is
exhausted. This will make the SCSI core reissue a SCSI command until
completion of another command has freed up one of the pre-allocated
requests. This is not the most efficient approach but should not trigger
a deadlock.
Thanks,
Bart.
Powered by blists - more mailing lists