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]
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)

Powered by blists - more mailing lists