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: <e9b912bca9fd48c9b2fd76bea80439ae@codeaurora.org>
Date:   Tue, 23 Mar 2021 12:33:22 +0800
From:   Can Guo <cang@...eaurora.org>
To:     Bean Huo <huobean@...il.com>
Cc:     daejun7.park@...sung.com, Greg KH <gregkh@...uxfoundation.org>,
        avri.altman@....com, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, asutoshd@...eaurora.org,
        stanley.chu@...iatek.com, bvanassche@....org,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        ALIM AKHTAR <alim.akhtar@...sung.com>,
        JinHwan Park <jh.i.park@...sung.com>,
        Javier Gonzalez <javier.gonz@...sung.com>,
        Sung-Jun Park <sungjun07.park@...sung.com>,
        Jinyoung CHOI <j-young.choi@...sung.com>,
        Dukhyun Kwon <d_hyun.kwon@...sung.com>,
        Keoseong Park <keosung.park@...sung.com>,
        Jaemyung Lee <jaemyung.lee@...sung.com>,
        Jieon Seol <jieon.seol@...sung.com>
Subject: Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read

On 2021-03-23 12:22, Can Guo wrote:
> On 2021-03-22 17:11, Bean Huo wrote:
>> On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
>>> +       switch (rsp_field->hpb_op) {
>>> 
>>> +       case HPB_RSP_REQ_REGION_UPDATE:
>>> 
>>> +               if (data_seg_len != DEV_DATA_SEG_LEN)
>>> 
>>> +                       dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
>>> 
>>> +                                "%s: data seg length is not
>>> same.\n",
>>> 
>>> +                                __func__);
>>> 
>>> +               ufshpb_rsp_req_region_update(hpb, rsp_field);
>>> 
>>> +               break;
>>> 
>>> +       case HPB_RSP_DEV_RESET:
>>> 
>>> +               dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
>>> 
>>> +                        "UFS device lost HPB information during
>>> PM.\n");
>>> 
>>> +               break;
>> 
>> Hi Deajun,
>> This series looks good to me. Just here I have one question. You 
>> didn't
>> handle HPB_RSP_DEV_RESET, just a warning.  Based on your SS UFS, how 
>> to
>> handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
>> reset host side HPB entry as well or what else?
>> 
>> 
>> Bean
> 
> Same question here - I am still collecting feedbacks from flash vendors 
> about
> what is recommanded host behavior on reception of HPB Op code 0x2, 
> since it
> is not cleared defined in HPB2.0 specs.
> 
> Can Guo.

I think the question should be asked in the HPB2.0 patch, since in 
HPB1.0 device
control mode, a HPB reset in device side does not impact anything in 
host side -
host is not writing back any HPB entries to device anyways and HPB Read 
cmd with
invalid HPB entries shall be treated as normal Read(10) cmd without any 
problems.
Please correct me if I am wrong.

Thanks,
Can Guo.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ