From: Christoph Hellwig <hch@lst.de>
To: Maximilian Heyne <mheyne@amazon.de>
Cc: Amit Shah <aams@amazon.de>,
stable@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: validate cntlid's only for nvme >= 1.1.0
Date: Tue, 30 Jun 2020 15:36:09 +0200 [thread overview]
Message-ID: <20200630133609.GA20809@lst.de> (raw)
In-Reply-To: <20200630133358.GA20602@lst.de>
On Tue, Jun 30, 2020 at 03:33:58PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 30, 2020 at 12:29:23PM +0000, Maximilian Heyne wrote:
> > Controller ID's (cntlid) for NVMe devices were introduced in version
> > 1.1.0 of the specification. Controllers that follow the older 1.0.0 spec
> > don't set this field so it doesn't make sense to validate it. On the
> > contrary, when using SR-IOV this check breaks VFs as they are all part
> > of the same NVMe subsystem.
> >
> > Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
> > Cc: <stable@vger.kernel.org> # 5.4+
>
> The first hunk looks ok, the second doesn't make sense as fabrics
> was only added with NVMe 1.2.2. I can fix it up when applying if you
> are ok with that.
>
> But you guys really shouldn't be doing SR-IOV with 1.0 controllers
> independent of this..
And actually - 1.0 did not have the concept of a subsystem. So having
a duplicate serial number for a 1.0 controller actually is a pretty
nasty bug. Can you point me to this broken controller? Do you think
the OEM could fix it up to report a proper version number and controller
ID?
next prev parent reply other threads:[~2020-06-30 13:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 12:29 [PATCH] nvme: validate cntlid's only for nvme >= 1.1.0 Maximilian Heyne
2020-06-30 13:33 ` Christoph Hellwig
2020-06-30 13:36 ` Christoph Hellwig [this message]
2020-06-30 14:01 ` Maximilian Heyne
2020-06-30 14:08 ` 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=20200630133609.GA20809@lst.de \
--to=hch@lst.de \
--cc=aams@amazon.de \
--cc=axboe@fb.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mheyne@amazon.de \
--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