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: <3a680224-8f45-4612-bc11-40515c30e7e8@bjorling.me>
Date: Wed, 9 Oct 2024 15:59:51 +0200
From: Matias Bjørling <m@...rling.me>
To: Hannes Reinecke <hare@...e.de>, kbusch@...nel.org, hch@....de,
 dlemoal@...nel.org, cassel@...nel.org, linux-nvme@...ts.infradead.org,
 linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Matias Bjørling <matias.bjorling@....com>
Subject: Re: [PATCH 1/2] nvme: make independent ns identify default

On 09-10-2024 08:16, Hannes Reinecke wrote:
> On 10/8/24 16:55, Matias Bjørling wrote:
>> From: Matias Bjørling <matias.bjorling@....com>
>>
>> The NVMe 2.0 specification adds an independent identify namespace
>> data structure that contains generic attributes that apply to all
>> namespace types. Some attributes carry over from the NVM command set
>> identify namespace data structure, and others are new.
>>
>> Currently, the data structure only considered when CRIMS is enabled or
>> when the namespace type is key-value.
>>
>> However, the independent namespace data structure
>> is mandatory for devices that implement features from the 2.0+
>> specification. Therefore, we can check this data structure first. If
>> unavailable, retrieve the generic attributes from the NVM command set
>> identify namespace data structure.
>>
>> Signed-off-by: Matias Bjørling <matias.bjorling@....com>
>> ---
>>   drivers/nvme/host/core.c | 7 +++----
>>   1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index 0dc8bcc664f2..9cbef6342c39 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -3999,7 +3999,7 @@ static void nvme_scan_ns(struct nvme_ctrl *ctrl, 
>> unsigned nsid)
>>   {
>>       struct nvme_ns_info info = { .nsid = nsid };
>>       struct nvme_ns *ns;
>> -    int ret;
>> +    int ret = 1;
>>       if (nvme_identify_ns_descs(ctrl, &info))
>>           return;
>> @@ -4015,10 +4015,9 @@ static void nvme_scan_ns(struct nvme_ctrl 
>> *ctrl, unsigned nsid)
>>        * data structure to find all the generic information that is 
>> needed to
>>        * set up a namespace.  If not fall back to the legacy version.
>>        */
>> -    if ((ctrl->cap & NVME_CAP_CRMS_CRIMS) ||
>> -        (info.ids.csi != NVME_CSI_NVM && info.ids.csi != NVME_CSI_ZNS))
>> +    if (!nvme_ctrl_limited_cns(ctrl))
>>           ret = nvme_ns_info_from_id_cs_indep(ctrl, &info);
>> -    else
>> +    if (ret > 0)
>>           ret = nvme_ns_info_from_identify(ctrl, &info);
>>       if (info.is_removed)
> 
> That is a very odd coding. 'info' will only be filled out for a non-zero
> return value of nvme_ns_info_from_cs_indep().

I may have misunderstood. Only if nvme_ns_info_from_cs_indep() return 0 
will the information be filled. Otherwise, if it is an NVMe error, 
nvme_ns_info_from_identify() is tried, otherwise it's a hard error, and 
it errors out completely.

> So why not check for that?
> But if we get an NVME status back there is a fair chance that something 
> else than 'invalid field' (or whatever indicated that the command is not 
> supported). That then would cause the device to be misdetected without 
> the admin knowning.
> Shouldn't we add a message if we fall back to nvme_ns_info_from_identify()?

Hmm, we could. Buuuut, at this point, there's more devices falling back 
to nvme_ns_info_from_identify(), than devices that implements the 
independent ns identify data structure. So I wouldn't mind it being 
silent. If we want to debug a potential misdetection, tracing could be 
enabled to track down what's happening.

> 
> Cheers,
> 
> Hannes


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ