linux-kernel - RE: [PATCH] scsi: ufs: Fix proper API to send HPB pre-request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211029015015epcms2p3a46e0779e43ab84c00388d99abf3b867@epcms2p3>
Date:   Fri, 29 Oct 2021 10:50:15 +0900
From:   Daejun Park <daejun7.park@...sung.com>
To:     Ming Lei <ming.lei@...hat.com>,
        Daejun Park <daejun7.park@...sung.com>
CC:     ALIM AKHTAR <alim.akhtar@...sung.com>,
        "avri.altman@....com" <avri.altman@....com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "huobean@...il.com" <huobean@...il.com>,
        "bvanassche@....org" <bvanassche@....org>,
        Keoseong Park <keosung.park@...sung.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] scsi: ufs: Fix proper API to send HPB pre-request

> On Thu, Oct 28, 2021 at 07:36:19AM +0900, Daejun Park wrote:
> > This patch addresses the issue of using the wrong API to create a
> > pre_request for HPB READ.
> > HPB READ candidate that require a pre-request will try to allocate a
> > pre-request only during request_timeout_ms (default: 0). Otherwise, it is
>  
> Can you explain about 'only during request_timeout_ms'?
>  
> From the following code in ufshpb_prep(), the pre-request is allocated
> for each READ IO in case of (!ufshpb_is_legacy(hba) && ufshpb_is_required_wb(hpb,
> transfer_len)).
>  
>    if (!ufshpb_is_legacy(hba) &&
>             ufshpb_is_required_wb(hpb, transfer_len)) {
>                 err = ufshpb_issue_pre_req(hpb, cmd, &read_id);
>  
> > passed as normal READ, so deadlock problem can be resolved.
> > 
> > Signed-off-by: Daejun Park <daejun7.park@...sung.com>
> > ---
> >  drivers/scsi/ufs/ufshpb.c | 11 +++++------
> >  drivers/scsi/ufs/ufshpb.h |  1 +
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> > index 02fb51ae8b25..3117bd47d762 100644
> > --- a/drivers/scsi/ufs/ufshpb.c
> > +++ b/drivers/scsi/ufs/ufshpb.c
> > @@ -548,8 +548,7 @@ static int ufshpb_execute_pre_req(struct ufshpb_lu *hpb, struct scsi_cmnd *cmd,
> >                                   read_id);
> >          rq->cmd_len = scsi_command_size(rq->cmd);
> >  
> > -        if (blk_insert_cloned_request(q, req) != BLK_STS_OK)
> > -                return -EAGAIN;
> > +        blk_execute_rq_nowait(NULL, req, true, ufshpb_pre_req_compl_fn);
>  
> Be care with above change, blk_insert_cloned_request() allocates
> driver tag and issues the request to LLD directly, then returns the
> result. If anything fails in the code path, -EAGAIN is returned.
>  
> But blk_execute_rq_nowait() simply queued the request in block layer,
> and run hw queue. It doesn't allocate driver tag, and doesn't issue it
> to LLD.
>  
> So ufshpb_execute_pre_req() may think the pre-request is issued to LLD
> successfully, but actually not, maybe never. What will happen after the
> READ IO is issued to device, but the pre-request(write buffer) isn't
> sent to device?

In that case, the HPB READ cannot get benefit from pre-request. But it is not
common case.

> Can you explain how this change solves the deadlock?

The deadlock is happen when the READ waiting allocation of pre-request. But
the timeout code makes to stop waiting after given time later.

Thanks,
Daejun