linux-kernel - Re: [PATCH 0/4] lightnvm: pblk: add support for chunk metadata on erase

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: <95ae2794-c671-5dc7-3a2d-2b062ea86fba@lightnvm.io>
Date:   Tue, 4 Sep 2018 11:54:23 +0200
From:   Matias Bjørling <mb@...htnvm.io>
To:     javier@...xlabs.com
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        hans.holmberg@...xlabs.com
Subject: Re: [PATCH 0/4] lightnvm: pblk: add support for chunk metadata on
 erase

On 09/03/2018 11:16 AM, Javier Gonzalez wrote:
>> On 31 Aug 2018, at 15.57, Matias Bjørling <mb@...htnvm.io> wrote:
>>
>> On 08/31/2018 03:34 PM, Javier González wrote:
>>> Matias,
>>> This patchset implements support for retrieving chunk metadata when
>>> submitting a reset/erase command. Patches 0 and 1 are small fixes that
>>> can be directly merged into your patch:
>>>       lightnvm: move bad block and chunk state logic to core
>>> Also, note that these do not apply on top of your for-4.20/core due them
>>> depending on patches that I sent before that you have not picked up yet.
>>> You can see them though in for-4.20/pblk. I'll rebase as patches in the
>>> list appear in your tree.
>>
>> Thanks. It is really confusing when you guys maintains an implicit order and posts the patches separately. I will appreciate that patches that are related are posted together, such that I don't have to manually track what comes before another. That makes it less of a pain for me to keep track of and we can keep the reviews together.
>>
>> This is the patches that I have in the pipeline (from before the e-mails from today):
>>
>>   - This serie - Pending review
>>   - Serie: pblk: support variable OOB size - Waiting on review from Igor
>>   - lightnvm: pblk: recover open lines on 2.0 devices. Which doesn't apply due to the fixes to the pad distance patch.
>>
> 
> Yes, I know and I apologize - we should have a better flow. What do you
> say that for windows like this, where we have a number of patches that
> have dependencies that we post them in meaningful patchsets and point to
> a branch where they are ordered, like in a PR? Then we can rebase and
> propagate changes properly?

I am with the patchset posted, that should have the order. I just wanted 
to mention it. One thing that would be good, if you do have patches you 
have upstream, feel free to push them in smaller increments, so we can 
pull them in as we go. Only a nitpick, it is obviously up to you guys 
how you want to do it :)

> 
> For this window, I'll rebase the rest of the patches in for-4.20/pblk on
> top of your for-4.20/core, then we can propagate changes as they come.
> 
> Javier
>