From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alex Gagniuc <Alex_Gagniuc@dellteam.com>
Cc: Jon Derrick <jonathan.derrick@intel.com>,
linux-nvme@lists.infradead.org,
Keith Busch <keith.busch@intel.com>, Jens Axboe <axboe@fb.com>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
mr.nuke.me@gmail.com
Subject: Re: [PATCH] nvme-pci: Prevent mmio reads if pci channel offline
Date: Sun, 24 Feb 2019 16:43:26 -0800 [thread overview]
Message-ID: <CAHk-=whSN1cPoOigEAcyBOjOFeKGL9kX3xvKgZ8SYqQQd2stQQ@mail.gmail.com> (raw)
In-Reply-To: <cbe2ed1562a64609be6538f5816ec1b6@ausx13mps321.AMER.DELL.COM>
On Sun, Feb 24, 2019 at 3:27 PM <Alex_Gagniuc@dellteam.com> wrote:
>
> >
> > It's not useful to panic just for random reasons. I realize that some
> > of the RAS people have the mindset that "hey, I don't know what's
> > wrong, so I'd better kill the machine than continue", but that's
> > bogus.
>
> That's the first thing I tried, but Borislav didn't like it. And he's
> right in the strictest sense of the ACPI spec: a fatal GHES error must
> result in a machine reboot [1].
>
> > What happens if we just fix that part?
>
> On rx740xd, on a NVMe hotplug bay, the upstream port stops sending
> hotplug interrupts. We could fix that with a quirk by clearing a
> proprietary bit in the switch. However, FFS won't re-arm itself to
> receive any further errors, so we'd never get notified in case there is
> a genuine error.
But this is not a genuine fatal error.
When spec and reality collide, the spec is just so much toilet paper.
In fact, the spec is worth _less_ than toilet paper, because at least
toilet paper is useful for wiping your butt clean. The spec? Not so
much.
> Keith Busch of Intel at some point suggested remapping all MMIO
> resources of a dead PCIe device to a read-only page that returns all
> F's. Neither of us were too sure how to do that, or how to handle the
> problem of in-flight DMA, which wouldn't hit the page tables.
I agree that that would be a really cute and smart way to fix things,
but no, right now I don't think we have any kind of infrastructure in
place to do something like that.
> > What is the actual ghes error? Is it the "unknown, just panic" case,
> > or something else?
>
> More like "fatal error, just panic". It looks like this (from a serial
> console):
>
> [ 57.680494] {1}[Hardware Error]: Hardware error from APEI Generic
> Hardware Error Source: 1
> [ 57.680495] {1}[Hardware Error]: event severity: fatal
Ok, so the ghes information is actively wrong, and tries to kill the
machine when it shouldn't be killed.
I seriously think that the correct thing is to fix the problem at the
*source* - ie the ghes driver. That's the only driver that should care
about "this platform is broken and sends invalid fatal errors".
So instead of adding hacks to the nvme driver, I think the hacks
should be in the ghes driver. Possibly just a black-list of "this
platform is known broken, don't even enable the ghes driver for it".
Or possibly a bit more fine-grained in the sense that it knows that
"ok, this particular kind of error is due to a hotplug event, the
driver will handle it without help from us, so ignore it".
Linus
next prev parent reply other threads:[~2019-02-25 0:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 1:05 [PATCH] nvme-pci: Prevent mmio reads if pci channel offline Jon Derrick
2019-02-22 21:28 ` Linus Torvalds
2019-02-22 21:59 ` Keith Busch
2019-02-24 20:37 ` Alex_Gagniuc
2019-02-24 22:42 ` Linus Torvalds
2019-02-24 23:27 ` Alex_Gagniuc
2019-02-25 0:43 ` Linus Torvalds [this message]
2019-02-25 15:55 ` Keith Busch
2019-02-26 22:37 ` Alex_Gagniuc
2019-02-27 1:01 ` Linus Torvalds
2019-02-27 16:42 ` Alex_Gagniuc
2019-02-27 17:51 ` Keith Busch
2019-02-27 18:07 ` Alex_Gagniuc
2019-02-27 17:55 ` Austin.Bolen
2019-02-27 20:04 ` Austin.Bolen
2019-02-28 14:16 ` Christoph Hellwig
2019-02-28 23:10 ` Austin.Bolen
2019-02-28 23:20 ` Keith Busch
2019-02-28 23:43 ` Austin.Bolen
2019-03-01 0:30 ` Keith Busch
2019-03-01 1:52 ` Austin.Bolen
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='CAHk-=whSN1cPoOigEAcyBOjOFeKGL9kX3xvKgZ8SYqQQd2stQQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=Alex_Gagniuc@dellteam.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=jonathan.derrick@intel.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mr.nuke.me@gmail.com \
--cc=sagi@grimberg.me \
/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).