linux-kernel - RE:(2) [PATCH v2] driver/nvme/host: Support duplicated nsid for the private ns

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: <20220315102438epcms2p68d757d1863b5582778f8c89517b82a70@epcms2p6>
Date:   Tue, 15 Mar 2022 19:24:38 +0900
From:   Sungup Moon <sungup.moon@...sung.com>
To:     "hch@....de" <hch@....de>, Sagi Grimberg <sagi@...mberg.me>
CC:     "kbusch@...nel.org" <kbusch@...nel.org>,
        "axboe@...com" <axboe@...com>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE:(2) [PATCH v2] driver/nvme/host: Support duplicated nsid for the
 private ns

First of all private namespace should be created by the vendor specific command,
because namespace management, ANA and NVM Set should be disabled on the controller
level. So Normal namespace managed NVMe deivce should return true using the
namespace management field (ctrl->oacs & NVME_CTRL_OACS_NS_MNGT_SUPP).

If user create using the namespace management admin command, my patch
check the namespace management field and that sub-system should be managed
like multi-path nvme device route.

So, if user create shared namespace on that nvme subsystem, should
distroy all namespace with target nsid, and create the new shared namespace
using the vendor specific admin command.

--------- Original Message ---------
Sender : hch@....de <hch@....de>
Date : 2022-03-15 17:46 (GMT+9)
Title : Re: [PATCH v2] driver/nvme/host: Support duplicated nsid for the private ns

On Tue, Mar 15, 2022 at 10:42:56AM +0200, Sagi Grimberg wrote:
>>>> +         * We also do this for private namespaces as the namespace sharing flag
>>>> +         * could change after a rescan.
>>>
>>> What happens in this case? we now have non-unique shared namespaces?
>>
>> The non-uniqueue NSIDs can only happen for private namespaces.
>
> But what happens if this changes upon a rescan as you commented?

Well, it can't change to shared as the nsids are non-unique.  If we
want to be paranoid we could add a sanity check for that, but then
again there are a bunch of other things where we could be more paranoid.