linux-kernel - Re: [PATCH] lightnvm: move device L2P detection to core

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: <C29BF7B1-4C9A-47C7-9E5F-AD63356B01BC@cnexlabs.com>
Date:   Fri, 3 Aug 2018 12:40:12 +0000
From:   Javier Gonzalez <javier@...xlabs.com>
To:     Matias Bjørling <mb@...htnvm.io>
CC:     "Konopko, Igor J" <igor.j.konopko@...el.com>,
        "marcin.dziegielewski@...el.com" <marcin.dziegielewski@...el.com>,
        Hans Holmberg <hans.holmberg@...xlabs.com>,
        Heiner Litz <hlitz@...c.edu>,
        Young Tack Tack Jin <youngtack.jin@...cuitblvd.com>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lightnvm: move device L2P detection to core

> On 3 Aug 2018, at 14.37, Matias Bjørling <mb@...htnvm.io> wrote:
> 
> On 08/03/2018 02:16 PM, Javier Gonzalez wrote:
>>> On 3 Aug 2018, at 10.54, Matias Bjørling <mb@...htnvm.io> wrote:
>>> 
>>> A 1.2 device is able to manage the logical to physical mapping
>>> table internally or leave it to the host.
>>> 
>>> A target only supports one of those approaches, and therefore must
>>> check on initialization. Move this check to core to avoid each target
>>> implement the check.
>>> 
>>> Signed-off-by: Matias Bjørling <mb@...htnvm.io>
>>> ---
>> I see where you want to go with these changes, but the way targets are
>> layered on top of the LightNVM subsystem does not align with it.
>> LightNVM can support different OCSSD versions and capabilities, but that
>> does not mean that a target (e.g., pblk) does. The way I see it, core
>> should only check for (i) the drive to expose itself in a known revision
>> and (ii) the reported structures to be consistent. However, specific
>> functionality is not for core to check upo.
> 
> Why try to initialize a target, if we already know that it is incompatible?

Yes, that is my point. But the one who knows if the targets supports
something or not is the target, not the subsystem. Here, you are making
an assumption knowing the pblk requires the L2P on the host, but that
could change in the future...

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)