Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <1d7c1faf6b6fa71599b5157ae95fc48ce479b722.camel@linux.ibm.com>
Subject: Re: [PATCH] scsi: ufs: Fix proper API to send HPB pre-request
From:   James Bottomley <jejb@linux.ibm.com>
Reply-To: jejb@linux.ibm.com
To:     Bart Van Assche <bvanassche@acm.org>, daejun7.park@samsung.com,
        ALIM AKHTAR <alim.akhtar@samsung.com>,
        "avri.altman@wdc.com" <avri.altman@wdc.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "huobean@gmail.com" <huobean@gmail.com>,
        Keoseong Park <keosung.park@samsung.com>
Cc:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>
Date:   Thu, 28 Oct 2021 15:12:28 -0400
In-Reply-To: <0d66b6d0-26c6-573f-e2a0-022e22c47b52@acm.org>
References: <CGME20211027223619epcms2p60bbc74c9ba9757c58709a99acd0892ff@epcms2p6>
         <20211027223619epcms2p60bbc74c9ba9757c58709a99acd0892ff@epcms2p6>
         <0f9229c3c4c7859524411a47db96a3b53ac89c90.camel@linux.ibm.com>
         <0d66b6d0-26c6-573f-e2a0-022e22c47b52@acm.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 2021-10-28 at 08:59 -0700, Bart Van Assche wrote:
> 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.

I think the deadlock is triggered if the system is down to its last
reserved request on the memory clearing device and the next entry in
the queue for this device is one which does a fanout so we can't
service it with the single reserved request we have left for the
purposes of making forward progress.  Sending it back doesn't help,
assuming this is the only memory clearing path, because retrying it
won't help ... we have to succeed with a request on this path to move
forward with clearing memory.

I think this problem could be solved by processing the WRITE BUFFER and
the request serially by hijacking the request sent down, but we can't
solve it if we try to allocate a new request.

James