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: <ed088511bfe2414a7f84a459b954192f9992af3b.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>,
        Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Thu, 28 Oct 2021 16:12:01 -0400
In-Reply-To: <42ca5f60-4c57-ade1-5fb7-be935ac4ccce@acm.org>
References: <CGME20211027223619epcms2p60bbc74c9ba9757c58709a99acd0892ff@epcms2p6>
         <20211027223619epcms2p60bbc74c9ba9757c58709a99acd0892ff@epcms2p6>
         <0f9229c3c4c7859524411a47db96a3b53ac89c90.camel@linux.ibm.com>
         <0d66b6d0-26c6-573f-e2a0-022e22c47b52@acm.org>
         <1d7c1faf6b6fa71599b5157ae95fc48ce479b722.camel@linux.ibm.com>
         <42ca5f60-4c57-ade1-5fb7-be935ac4ccce@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 13:04 -0700, Bart Van Assche wrote:
> On 10/28/21 12:12 PM, James Bottomley wrote:
> > 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.
> 
> Hi James,
> 
> How about fixing the abuse of blk_insert_cloned_request() in the UFS
> HPB before the v5.16 SCSI pull request is sent to Linus and
> implementing the proposal from your email at a later time? I'm
> proposing to defer further UFS HPB rework since the issue described
> above only affects UFS HPB users and does not obstruct maintenance or
> refactoring of the block layer core.

Well, yes, I'm already on record as saying we need to do that and add
the functionality back compatibly in a later release.  I think excising
the WRITE BUFFER path, which is simply an optimization and will affect
performance but not function, solves the above issue (and the clone API
problem as well) completely but I haven't heard the patch I proposed
has actually been tested yet.

James