linux-kernel - Re: [RFC PATCH v2 4/5] scsi: ufs: L2P map management for HPB read

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]

Date:   Mon, 15 Jun 2020 15:35:47 +0200
From:   Bean Huo <huobean@...il.com>
To:     daejun7.park@...sung.com, 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>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>,
        "bvanassche@....org" <bvanassche@....org>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>
Cc:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sang-yoon Oh <sangyoon.oh@...sung.com>,
        Sung-Jun Park <sungjun07.park@...sung.com>,
        yongmyung lee <ymhungry.lee@...sung.com>,
        Jinyoung CHOI <j-young.choi@...sung.com>,
        Adel Choi <adel.choi@...sung.com>,
        BoRam Shin <boram.shin@...sung.com>
Subject: Re: [RFC PATCH v2 4/5] scsi: ufs: L2P map management for HPB read

Hi Daejun


On Mon, 2020-06-15 at 18:30 +0900, Daejun Park wrote:
> +static int ufshpb_execute_map_req(struct ufshpb_lu *hpb,
> +                                 struct ufshpb_req *map_req)
> +{
> +       struct request_queue *q;
> +       struct request *req;
> +       struct scsi_request *rq;
> +       int ret = 0;
> +
> +       q = hpb->sdev_ufs_lu->request_queue;
> +       ret = ufshpb_map_req_add_bio_page(hpb, q, map_req->bio,
> +                                         map_req->mctx);
> +       if (ret) {
> +               dev_notice(&hpb->hpb_lu_dev,
> +                          "map_req_add_bio_page fail %d - %d\n",
> +                          map_req->rgn_idx, map_req->srgn_idx);
> +               return ret;
> +       }
> +
> +       req = map_req->req;
> +
> +       blk_rq_append_bio(req, &map_req->bio);
> +
> +       req->timeout = 0;
> +       req->end_io_data = (void *)map_req;
> +
> +       rq = scsi_req(req);
> +       ufshpb_set_read_buf_cmd(rq->cmd, map_req->rgn_idx,
> +                               map_req->srgn_idx, hpb-
> >srgn_mem_size);
> +       rq->cmd_len = HPB_READ_BUFFER_CMD_LENGTH;
> +
> +       blk_execute_rq_nowait(q, NULL, req, 1,
> ufshpb_map_req_compl_fn);


HPB map_req is now being en-queued in sdev->request_queue.
This is ok for the HPB v1.0. Have you ever been thinking about
changing this way to directly issue HPB requests to UFS?

Actually, there are two reasons for this way:

1. Latency of loading mapping entries is lower comparing to your curret
approach.
2. Also, it is preparing for the HPB v2.0.  After all HPB 1.0 only
supports 4KB read, this is useless, I am looking for the HPB v2.0.


Thanks,
Bean