public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Igor Konopko <igor.j.konopko@intel.com>
To: "Hans Holmberg" <hans@owltronix.com>, "Matias Bjørling" <mb@lightnvm.io>
Cc: "Javier González" <javier@javigon.com>,
	"Hans Holmberg" <hans.holmberg@cnexlabs.com>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH 06/13] lightnvm: pblk: Ensure that erase is chunk aligned
Date: Tue, 5 Mar 2019 09:26:19 +0100	[thread overview]
Message-ID: <0cd6b922-c622-6946-b182-77176967e63b@intel.com> (raw)
In-Reply-To: <CANr-nt0HuEnEPhAQC10xEFud4SHqcC662==1njSP8Ag2ue4UKA@mail.gmail.com>



On 05.03.2019 09:20, Hans Holmberg wrote:
> On Mon, Mar 4, 2019 at 2:00 PM Matias Bjørling <mb@lightnvm.io> wrote:
>>
>> On 3/4/19 1:44 PM, Igor Konopko wrote:
>>>
>>>
>>> On 04.03.2019 12:43, Hans Holmberg wrote:
>>>> On Mon, Mar 4, 2019 at 10:11 AM Javier González <javier@javigon.com>
>>>> wrote:
>>>>>
>>>>>> On 4 Mar 2019, at 10.05, Hans Holmberg
>>>>>> <hans.ml.holmberg@owltronix.com> wrote:
>>>>>>
>>>>>> I strongly disagree with adding code that would mask implantation
>>>>>> errors.
>>>>>>
>>>>>> If we want more internal checks, we could add an if statement that
>>>>>> would only be compiled in if CONFIG_NVM_PBLK_DEBUG is enabled.
>>>>>>
>>>>>
>>>>> Not sure who this is for - better not to top post.
>>>>>
>>>>> In any case, this is a spec grey zone. I’m ok with cleaning the bits as
>>>>> they mean nothing for the reset command. If you feel that strongly about
>>>>> this, you can take if with Igor.
>>>>
>>>> Pardon the top-post. It was meant for both you and Igor.
>>>>
>>>
>>> OCSSD 2.0 spec for vector chunk reset (chapter 2.2.2) explicitly says
>>> "The addresses in the LBA list shall be the first logical block address
>>> of each chunk to be reset.". So in my understanding we suppose to clear
>>> the sectors bits of the PPA address in order to be spec compliant.
>>>
>>
>> Agree. And since ppa_addr is allocated on the stack, it should be either
>> memset or the remaining fields should be set to 0. Maybe better to zero
>> initialize in declaration?
> 
> Ah, I thought this was not needed, as ppa is initialized as:
> 
> ppa = pblk->luns[bit].bppa; /* set ch and lun */
> 
> and luns[bit].bppa is initialized to on a value that originally comes
> from drivers/lightnvm/core.c:196
> (and that's explicitly zeroing all 64 bits before setting ch and lun)
> 
> Let me know if i don't make sense here.
> 

I just noticed the same.

In two places (pblk-core:1095 and pblk-map:205) we are using values 
initialized previously in core.c - so my changes are not needed here.

But still there is one place (pblk-map:163) where we initializing 
erase_ppa based on ppa_list[i], which has PPA sector set in most of the 
cases, so this zeroing is still needed here.

>>
>>>>>
>>>>>>
>>>>>> On Mon, Mar 4, 2019 at 8:48 AM Javier González <javier@javigon.com>
>>>>>> wrote:
>>>>>>>> On 27 Feb 2019, at 18.14, Igor Konopko <igor.j.konopko@intel.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> In current pblk implementation of erase command
>>>>>>>> there is a chance tha sector bits are set to some
>>>>>>>> random values for erase PPA. This is unexpected
>>>>>>>> situation, since erase shall be always chunk
>>>>>>>> aligned. This patch fixes that issue
>>>>>>>>
>>>>>>>> Signed-off-by: Igor Konopko <igor.j.konopko@intel.com>
>>>>>>>> ---
>>>>>>>> drivers/lightnvm/pblk-core.c | 1 +
>>>>>>>> drivers/lightnvm/pblk-map.c  | 2 ++
>>>>>>>> 2 files changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/lightnvm/pblk-core.c
>>>>>>>> b/drivers/lightnvm/pblk-core.c
>>>>>>>> index a98b2255f963..78b1eea4ab67 100644
>>>>>>>> --- a/drivers/lightnvm/pblk-core.c
>>>>>>>> +++ b/drivers/lightnvm/pblk-core.c
>>>>>>>> @@ -978,6 +978,7 @@ int pblk_line_erase(struct pblk *pblk, struct
>>>>>>>> pblk_line *line)
>>>>>>>>
>>>>>>>>                ppa = pblk->luns[bit].bppa; /* set ch and lun */
>>>>>>>>                ppa.a.blk = line->id;
>>>>>>>> +             ppa.a.reserved = 0;
>>>>>>>>
>>>>>>>>                atomic_dec(&line->left_eblks);
>>>>>>>>                WARN_ON(test_and_set_bit(bit, line->erase_bitmap));
>>>>>>>> diff --git a/drivers/lightnvm/pblk-map.c
>>>>>>>> b/drivers/lightnvm/pblk-map.c
>>>>>>>> index 79df583ea709..aea46b4ec40f 100644
>>>>>>>> --- a/drivers/lightnvm/pblk-map.c
>>>>>>>> +++ b/drivers/lightnvm/pblk-map.c
>>>>>>>> @@ -161,6 +161,7 @@ int pblk_map_erase_rq(struct pblk *pblk,
>>>>>>>> struct nvm_rq *rqd,
>>>>>>>>
>>>>>>>>                        *erase_ppa = ppa_list[i];
>>>>>>>>                        erase_ppa->a.blk = e_line->id;
>>>>>>>> +                     erase_ppa->a.reserved = 0;
>>>>>>>>
>>>>>>>>                        spin_unlock(&e_line->lock);
>>>>>>>>
>>>>>>>> @@ -202,6 +203,7 @@ int pblk_map_erase_rq(struct pblk *pblk,
>>>>>>>> struct nvm_rq *rqd,
>>>>>>>>                atomic_dec(&e_line->left_eblks);
>>>>>>>>                *erase_ppa = pblk->luns[bit].bppa; /* set ch and lun */
>>>>>>>>                erase_ppa->a.blk = e_line->id;
>>>>>>>> +             erase_ppa->a.reserved = 0;
>>>>>>>>        }
>>>>>>>>
>>>>>>>>        return 0;
>>>>>>>> --
>>>>>>>> 2.17.1
>>>>>>>
>>>>>>> I’m fine with adding this, but note that there is actually no
>>>>>>> requirement for the erase to be chunk aligned - the only bits that
>>>>>>> should be looked at are group, PU and chunk.
>>>>>>>
>>>>>>> Reviewed-by: Javier González <javier@javigon.com>
>>

  reply	other threads:[~2019-03-05  8:26 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 17:14 [PATCH 00/13] lightnvm: bugfixes and improvements Igor Konopko
2019-02-27 17:14 ` [PATCH 01/13] lightnvm: pblk: Line reference fix in GC Igor Konopko
2019-03-01 12:20   ` Hans Holmberg
2019-03-04  7:18   ` Javier González
2019-03-04 12:40   ` Matias Bjørling
2019-02-27 17:14 ` [PATCH 02/13] lightnvm: pblk: Gracefully handle GC data malloc fail Igor Konopko
2019-02-28 17:08   ` Javier González
2019-03-01 12:50     ` Hans Holmberg
2019-03-04 12:38       ` Igor Konopko
2019-02-27 17:14 ` [PATCH 03/13] lightnvm: pblk: Fix put line back behaviour Igor Konopko
2019-03-01 13:27   ` Hans Holmberg
2019-03-04  7:22   ` Javier González
2019-02-27 17:14 ` [PATCH 04/13] lightnvm: pblk: Rollback in gc read Igor Konopko
2019-03-04  7:38   ` Javier González
2019-03-04  8:44     ` Hans Holmberg
2019-03-04 12:39       ` Igor Konopko
2019-03-04 12:42         ` Hans Holmberg
2019-03-04 12:49   ` Matias Bjørling
2019-02-27 17:14 ` [PATCH 05/13] lightnvm: pblk: Count all read errors in stats Igor Konopko
2019-03-04  7:42   ` Javier González
2019-03-04  9:02     ` Hans Holmberg
2019-03-04  9:23       ` Javier González
2019-03-04 11:41         ` Hans Holmberg
2019-03-04 11:45           ` Javier González
2019-03-04 12:42             ` Igor Konopko
2019-03-04 12:48               ` Hans Holmberg
2019-02-27 17:14 ` [PATCH 06/13] lightnvm: pblk: Ensure that erase is chunk aligned Igor Konopko
2019-03-04  7:48   ` Javier González
2019-03-04  9:05     ` Hans Holmberg
2019-03-04  9:11       ` Javier González
2019-03-04 11:43         ` Hans Holmberg
2019-03-04 12:44           ` Igor Konopko
2019-03-04 12:57             ` Hans Holmberg
2019-03-04 13:00             ` Matias Bjørling
2019-03-05  8:20               ` Hans Holmberg
2019-03-05  8:26                 ` Igor Konopko [this message]
2019-03-05  8:40                   ` Hans Holmberg
     [not found]                     ` <61b7e62a-d229-95b1-2572-336ab1bd67cb@intel.com>
2019-03-05  8:55                       ` Hans Holmberg
2019-02-27 17:14 ` [PATCH 07/13] lightnvm: pblk: Cleanly fail when there is not enough memory Igor Konopko
2019-03-04  7:53   ` Javier González
2019-03-04  9:24     ` Hans Holmberg
2019-03-04 12:46       ` Igor Konopko
2019-02-27 17:14 ` [PATCH 08/13] lightnvm: pblk: Set proper read stutus in bio Igor Konopko
2019-03-04  8:03   ` Javier González
2019-03-04  9:35     ` Hans Holmberg
2019-03-04  9:48       ` Javier González
2019-03-04 12:14         ` Hans Holmberg
2019-03-04 12:51           ` Igor Konopko
2019-03-04 13:08             ` Matias Bjørling
2019-03-04 13:45               ` Javier González
2019-03-04 15:12                 ` Matias Bjørling
2019-03-05  6:43                   ` Javier González
2019-03-04 13:04         ` Matias Bjørling
2019-03-04 13:21           ` Javier González
2019-02-27 17:14 ` [PATCH 09/13] lightnvm: pblk: Kick writer for flush requests Igor Konopko
2019-03-04  8:08   ` Javier González
2019-03-04  9:39     ` Hans Holmberg
2019-03-04 12:52       ` Igor Konopko
2019-02-27 17:14 ` [PATCH 10/13] lightnvm: pblk: Reduce L2P DRAM footprint Igor Konopko
2019-03-04  8:17   ` Javier González
2019-03-04  9:29     ` Hans Holmberg
2019-03-04 13:11   ` Matias Bjørling
2019-02-27 17:14 ` [PATCH 11/13] lightnvm: pblk: Remove unused smeta_ssec field Igor Konopko
2019-03-04  8:21   ` Javier González
2019-03-04  9:40     ` Hans Holmberg
2019-02-27 17:14 ` [PATCH 12/13] lightnvm: pblk: close opened chunks Igor Konopko
2019-03-04  8:27   ` Javier González
2019-03-04 10:05     ` Hans Holmberg
2019-03-04 12:56       ` Igor Konopko
2019-03-04 13:03         ` Hans Holmberg
2019-03-04 13:19       ` Matias Bjørling
2019-03-04 13:48         ` Javier González
2019-03-04 13:18     ` Matias Bjørling
2019-03-04 13:47       ` Javier González
2019-02-27 17:14 ` [PATCH 13/13] lightnvm: Inherit mdts from the parent nvme device Igor Konopko
2019-03-04  9:05   ` Javier González
2019-03-04 11:30     ` Hans Holmberg
2019-03-04 11:44       ` Javier González
2019-03-04 12:22         ` Hans Holmberg
2019-03-04 13:04           ` Igor Konopko
2019-03-04 13:16             ` Hans Holmberg
2019-03-04 14:06             ` Javier González
2019-03-04 13:19           ` Javier González
2019-03-04 13:25             ` Matias Bjørling
2019-03-04 13:44               ` Javier González
2019-03-04 14:24                 ` Hans Holmberg
2019-03-04 14:27                   ` Javier González
2019-03-04 14:58                 ` Matias Bjørling
2019-02-28 16:36 ` [PATCH 00/13] lightnvm: bugfixes and improvements Matias Bjørling
2019-02-28 17:15   ` Javier González
2019-03-01 10:23   ` Hans Holmberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0cd6b922-c622-6946-b182-77176967e63b@intel.com \
    --to=igor.j.konopko@intel.com \
    --cc=hans.holmberg@cnexlabs.com \
    --cc=hans@owltronix.com \
    --cc=javier@javigon.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mb@lightnvm.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox