linux-kernel - Re: [RFC] nvme: Do not reject dynamic controller cntlid

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] [day] [month] [year] [list]

Message-ID: <e3cdb1c4-dbdc-abf9-8a7b-d272960ae382@suse.de>
Date:   Fri, 28 Jan 2022 18:06:19 +0100
From:   Hannes Reinecke <hare@...e.de>
To:     Daniel Wagner <dwagner@...e.de>, Keith Busch <kbusch@...nel.org>
Cc:     linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] nvme: Do not reject dynamic controller cntlid

On 1/28/22 13:36, Daniel Wagner wrote:
> On Fri, Jan 28, 2022 at 11:31:37AM +0100, Daniel Wagner wrote:
>> On Thu, Jan 27, 2022 at 09:17:58AM -0800, Keith Busch wrote:
>>>> +static inline bool nvme_ctrl_dynamic(struct nvme_ctrl *ctrl)
>>>> +{
>>>> +	return ctrl->cntlid == 0xffff;
>>>> +}
>>>
>>> It's probably safe to assume 0xffff is dynamic, but spec suggests we
>>> check ID_CTRL.FCATT bit 0.
>>
>> Okay, but this one is only defined for fabrics. I haven't found anything
>> so far which is equivalent to FCATT bit 0 for memory based transport.
> 
> Never mind. After discussing it with Hannes it turns out there is no
> problem here. I didn't understand the spec correctly (it's difficult to
> get an exact answer) on this topic.
> 
Weasely wording in the spec again.
It talks at great length on controller IDs for fabrics, which values are 
allowed and which not, and how one should do dynamic controller ids _on 
fabrics_, but is strangely silent for memory-based (ie PCI) transports.
There, apparently, 0xFFFF _is_ a valid controller id, and the only 
restriction is that the controller ID must be unique.
And even that is never stated directly, but must be inferred from the 
various command payload descriptions.
Guess it's a topic for the fmds call.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@...e.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer