linux-kernel - Re: [PATCH 1/2] nvme: make independent ns identify default

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: <ZwaZoJayzu6XZom1@kbusch-mbp>
Date: Wed, 9 Oct 2024 08:56:32 -0600
From: Keith Busch <kbusch@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Matias Bjørling <m@...rling.me>, dlemoal@...nel.org,
	cassel@...nel.org, linux-nvme@...ts.infradead.org,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	Matias Bjørling <matias.bjorling@....com>
Subject: Re: [PATCH 1/2] nvme: make independent ns identify default

On Wed, Oct 09, 2024 at 09:46:11AM +0200, Christoph Hellwig wrote:
> On Tue, Oct 08, 2024 at 04:55:02PM +0200, Matias Bjørling wrote:
> > 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.
> 
> I'm not a huge fan of this.  For pre-2.0 controllers this means
> we'll now send a command that will fail most of them time.  And for
> all the cheap low-end consumer device I'm actually worried that they'll
> get it wrong and break something.

We already send identify commands that we expect may break on pre-2.0
controllers: the Identify NS Descriptor List.

We have other quirks for disabling specific identifications (ex:
nvme_ctrl_limited_cns, NVME_QUIRK_NO_NS_DESC_LIST) in case something
really break certain identifies. But I think anything >= 1.3 should be
fine: the CNS handling is well defined from that point onward, so we
shouldn't make anything harder than necessary from assuming someone got
identication this wrong.

The only pain I can think of is that some controllers increment their
error log count, and SMART tools creates unnecessary alerts for that.