From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Ingo Brunberg <ingo_brunberg@web.de>,
linux-nvme@lists.infradead.org, "Nadolski,
Edmund" <edmund.nadolski@intel.com>,
Sagi Grimberg <sagi@grimberg.me>,
stable@vger.kernel.org
Subject: Re: [PATCH] nvme: Namepace identification descriptor list is optional
Date: Tue, 3 Dec 2019 01:49:03 +0900 [thread overview]
Message-ID: <20191202164903.GA21650@redsun51.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <20191202162905.GA7683@lst.de>
On Mon, Dec 02, 2019 at 05:29:05PM +0100, Christoph Hellwig wrote:
> On Mon, Dec 02, 2019 at 09:27:14AM -0700, Nadolski, Edmund wrote:
> >> I don't have such a controller, but many apparently do. The regression
> >> was reported here:
> >>
> >> http://lists.infradead.org/pipermail/linux-nvme/2019-December/028223.html
> >>
> >> And of course it's the SMI controller ...
> >
> > Does 5.4 show the exact error code? Perhaps we should selectively allow
> > just for that case?
>
> They'll find other ways to f***ck up. Looks like at least the controller
> in the bug report also doesn't have an subnqn and the nguid/eui64 are
> bogus.
Indeed, they will find creative ways to break it.
Customer or OEM requirments are poorly written, like "Must report NVMe
version 1.3". Nobody bothers to mention that it must also be compliant
to that version, or even realize they never cared for those features in
the first place.
Compliance testing like from UNH should have caught this before shipping
with such a device, but it's a cheap device, so maybe they skip that step.
> I wonder if we actually do users a favour by allowing that..
I think it's too late now. We did successfully use such namespaces
before 5.4, even if they're fundamentally broken.
Johannes also commented *not* to consider these errors when this
identification was originally implemented, so either he knew vendors
screwed this up, or had the forethought to know they would.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2019-12-02 16:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 15:56 [PATCH] nvme: Namepace identification descriptor list is optional Keith Busch
2019-12-02 16:15 ` Christoph Hellwig
2019-12-02 16:22 ` Keith Busch
2019-12-02 16:27 ` Nadolski, Edmund
2019-12-02 16:29 ` Christoph Hellwig
2019-12-02 16:45 ` Nadolski, Edmund
2019-12-02 16:49 ` Keith Busch [this message]
2019-12-02 17:34 ` Christoph Hellwig
2019-12-02 21:21 ` Keith Busch
2020-07-10 8:22 ` Ingo Brunberg
2020-07-22 23:23 ` Sagi Grimberg
2020-07-23 1:23 ` Ingo Brunberg
2020-07-28 11:08 ` Christoph Hellwig
2020-07-28 14:41 ` Ingo Brunberg
2020-07-28 16:01 ` Sagi Grimberg
[not found] <d163890a-a469-e71c-45b7-f63e1efee04e@intel.com>
2020-07-12 9:31 ` Ingo Brunberg
2020-07-12 17:03 ` Rajashekar, Revanth
2020-07-14 15:21 ` Keith Busch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191202164903.GA21650@redsun51.ssa.fujisawa.hgst.com \
--to=kbusch@kernel.org \
--cc=edmund.nadolski@intel.com \
--cc=hch@lst.de \
--cc=ingo_brunberg@web.de \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).