From: Borislav Petkov <bp@alien8.de>
To: James Morse <james.morse@arm.com>
Cc: David Arcari <darcari@redhat.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Lenny Szubowicz <lszubowi@redhat.com>,
Len Brown <lenb@kernel.org>, Tony Luck <tony.luck@intel.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexandru Gagniuc <mr.nuke.me@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPI/APEI: Clear GHES block_status before panic()
Date: Fri, 21 Dec 2018 19:59:37 +0100 [thread overview]
Message-ID: <20181221185937.GL1325@zn.tnic> (raw)
In-Reply-To: <0bb80989-4fe5-c320-8ffc-0f39502110c9@arm.com>
On Fri, Dec 21, 2018 at 06:52:20PM +0000, James Morse wrote:
> Do we need to ghes_ack_error() too?
That's GHES v2 AFAICT.
> With the location cleared the new kernel will never find the records, and
> firmware can never re-use that location because it wasn't ack'd. The upshot is
> RAS records can't be generated for the kdump kernel. The acpi spec talks about
> use of the memory, so I don't think its fair for it to use this to disarm a
> watchdog.
>
> I think we can live with this as the kdump kernel isn't going to handle RAS
> errors for the bulk of memory anyway.
Usually, handling hw errors is always better than not but the second
kernel can't do anything better in that respect than the first, right?
If it panics, it panics - no matter the kernel. Generally.
Therefore I think the role of the second kernel should be to be as
resilient as possible to hw errors - like, not even see them :-) - dump
the memory of the first kernel as quickly as possible and reboot for
analysis.
IMHO, of course.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
prev parent reply other threads:[~2018-12-21 18:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 16:50 [PATCH] ACPI/APEI: Clear GHES block_status before panic() David Arcari
2018-12-20 18:28 ` Tyler Baicar
2018-12-20 19:24 ` Borislav Petkov
2018-12-21 11:17 ` Rafael J. Wysocki
2018-12-21 18:52 ` James Morse
2018-12-21 18:59 ` Borislav Petkov [this message]
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=20181221185937.GL1325@zn.tnic \
--to=bp@alien8.de \
--cc=darcari@redhat.com \
--cc=ebiederm@xmission.com \
--cc=james.morse@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lszubowi@redhat.com \
--cc=mr.nuke.me@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
/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