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: <31319710-8A72-49DC-9CFA-521CA06843F3@cnexlabs.com>
Date:   Fri, 3 Aug 2018 12:16:39 +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 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.

In this particular case, the NVM_TGT_F_HOST_L2P check should be pblk
specific, as it is indeed a 1.2 capability not supported by pblk.
However, a different target supporting this 1.2 feature can be
implemented on top.

As mentioned before, I started looking at moving checks to core too and
my initial thought was to add a .capabilities entry to nvm_tgt_type{} so
that these can be checked prior target initialization. Alternatively, we
can move all these checks to pblk-init.c. At this point, it is safe to
push 1.2 / 2.0 specific functionality to core as registered targets
would have validated the spec and the actual supported capabilities.

Thoughts?

Javier

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