From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Keith Busch <kbusch@kernel.org>
Cc: "Keith Busch" <kbusch@meta.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>,
"Cláudio Sampaio" <patola@gmail.com>,
"Felix Yan" <felixonmars@archlinux.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] nvme: avoid bogus CRTO values
Date: Fri, 15 Sep 2023 21:31:44 +0000 [thread overview]
Message-ID: <ZQTNP5lnFFn8ThkZ@x1-carbon> (raw)
In-Reply-To: <ZQHnUMlm80Xzxn6n@kbusch-mbp.dhcp.thefacebook.com>
On Wed, Sep 13, 2023 at 09:46:08AM -0700, Keith Busch wrote:
>
> > I guess that I just can't understand how a controller can set
> > bit CAP.CRMS.CRWMS to 1, without setting a value in CRTO.CRWMT.
> > Is it such a silly spec violation, that they seem to have not
> > bothered to read what this bit means at all.
>
> Yep, but broken controllers are broken. They used to work in Linux
> before the driver started preferring the recommended CRTO, so we gotta
> fix 'em.
I'm not saying that these controllers shouldn't work with Linux.
However, these controller used to work with CC.CRIME == 0, so perhaps
we should continue to use them that way?
My reasoning is that if the controller did not even manage to get the
most fundamental part of this new feature correctly (i.e. defining the
actual timeout values for this feature), then perhaps we shouldn't
assume that the rest of the feature, setting the NRDY bit, sending the
AER, etc., is implemented correctly either.
When CC.CRIME == 1, both fields in CRTO actually have a defined meaning:
CRTO.CRIMT is the maximum time that host software should wait for the
controller to become ready.
CRTO.CRWMT is the maximum time that host software should wait for all
attached namespaces to become ready.
So having both fields defined to zero, or rather, to have both fields
defined to a value smaller than CAP.TO, regardless of CC.CRIME value,
is quite bad.
So perhaps it is better to keep CC.CRIME == 0 for such controllers.
> If we have a way to sanity check for spec non-compliance, I would prefer
> doing that generically rather than quirk specific devices.
It's not going to be beautiful, but one way could be to:
-check CAP.CRMS.CRIMS, if it is set to 1:
-write CC.CRIME == 1,
-re-read CAP register, since it can change depending on CC.CRIME (urgh)
-check if CRTO.CRIMT is less than CAP.TO, if so:
-write CC.CRIME == 0 (disable the feature since it is obviously broken)
-re-read CAP register, since it can change depending on CC.CRIME (urgh)
For the record, I'm obviously happy with whatever decision you make,
I'm just giving my two cents...
Kind regards,
Niklas
next prev parent reply other threads:[~2023-09-15 21:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 21:47 [PATCH] nvme: avoid bogus CRTO values Keith Busch
2023-09-13 10:50 ` Christoph Hellwig
2023-09-13 15:15 ` Keith Busch
2023-09-13 10:53 ` Sagi Grimberg
2023-09-13 12:25 ` Niklas Cassel
2023-09-13 15:20 ` Keith Busch
2023-09-13 16:14 ` Niklas Cassel
2023-09-13 16:46 ` Keith Busch
2023-09-15 21:31 ` Niklas Cassel [this message]
2023-09-15 21:50 ` Keith Busch
2023-09-15 22:14 ` Niklas Cassel
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=ZQTNP5lnFFn8ThkZ@x1-carbon \
--to=niklas.cassel@wdc.com \
--cc=felixonmars@archlinux.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-nvme@lists.infradead.org \
--cc=patola@gmail.com \
--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