From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Tyler Baicar <tbaicar@codeaurora.org>,
christoffer.dall@linaro.org, marc.zyngier@arm.com,
pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk,
catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net,
lenb@kernel.org, matt@codeblueprint.co.uk,
robert.moore@intel.com, lv.zheng@intel.com, mark.rutland@arm.com,
james.morse@arm.com, akpm@linux-foundation.org,
sandeepa.s.prabhu@gmail.com, shijie.huang@arm.com,
paul.gortmaker@windriver.com, tomasz.nowicki@linaro.org,
fu.wei@linaro.org, rostedt@goodmis.org, bristot@redhat.com,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, Dkvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-efi@vger.kernel.org, devel@acpica.org
Cc: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
Subject: Re: [PATCH V3 06/10] acpi: apei: panic OS with fatal error status block
Date: Thu, 13 Oct 2016 14:00:30 +0100 [thread overview]
Message-ID: <bf911628-71be-0dca-f1c7-c12e681bd37f@arm.com> (raw)
In-Reply-To: <1475875882-2604-7-git-send-email-tbaicar@codeaurora.org>
On 07/10/16 22:31, Tyler Baicar wrote:
> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
>
> Even if an error status block's severity is fatal, the kernel does not
> honor the severity level and panic.
>
> With the firmware first model, the platform could inform the OS about a
> fatal hardware error through the non-NMI GHES notification type. The OS
> should panic when a hardware error record is received with this
> severity.
>
> Call panic() after CPER data in error status block is printed if
> severity is fatal, before each error section is handled.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> ---
> drivers/acpi/apei/ghes.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 28d5a09..36894c8 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -141,6 +141,8 @@ static unsigned long ghes_estatus_pool_size_request;
> static struct ghes_estatus_cache *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
> static atomic_t ghes_estatus_cache_alloced;
>
> +static int ghes_panic_timeout __read_mostly = 30;
> +
> static int ghes_ioremap_init(void)
> {
> ghes_ioremap_area = __get_vm_area(PAGE_SIZE * GHES_IOREMAP_PAGES,
> @@ -715,6 +717,12 @@ static int ghes_proc(struct ghes *ghes)
> if (ghes_print_estatus(NULL, ghes->generic, ghes->estatus))
> ghes_estatus_cache_add(ghes->generic, ghes->estatus);
> }
> + if (ghes_severity(ghes->estatus->error_severity) >= GHES_SEV_PANIC) {
> + if (panic_timeout == 0)
> + panic_timeout = ghes_panic_timeout;
> + panic("Fatal hardware error!");
I think there is a chance that we might miss the o/p of ghes_print_estatus() as we use
no pfx, and it could default to the normal loglevel and would never get printed
if panic() is encountered before it. On the other hand, there is already a
__ghes_panic() which does similar stuff. Is there a way we could reuse
(may be even parts of) it ? Or at least use KERN_EMERG for the ghes_print_estatus(),
if the severity could result in panic() ?
Cheers
Suzuki
next prev parent reply other threads:[~2016-10-13 13:00 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-07 21:31 [PATCH V3 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Tyler Baicar
2016-10-07 21:31 ` [PATCH V3 01/10] acpi: apei: read ack upon ghes record consumption Tyler Baicar
2016-10-12 15:39 ` Punit Agrawal
2016-10-13 13:49 ` Baicar, Tyler
2016-10-07 21:31 ` [PATCH V3 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Tyler Baicar
2016-10-11 17:28 ` Suzuki K Poulose
2016-10-12 22:10 ` Baicar, Tyler
2016-10-13 8:50 ` Suzuki K Poulose
2016-10-13 19:37 ` Baicar, Tyler
2016-10-14 16:28 ` Suzuki K Poulose
2016-10-14 16:39 ` Mark Rutland
2016-10-11 18:52 ` Russell King - ARM Linux
2016-10-12 22:18 ` Baicar, Tyler
2016-10-07 21:31 ` [PATCH V3 03/10] efi: parse ARMv8 processor error Tyler Baicar
2016-10-07 21:31 ` [PATCH V3 04/10] arm64: exception: handle Synchronous External Abort Tyler Baicar
2016-10-12 17:46 ` Punit Agrawal
2016-10-13 13:56 ` Baicar, Tyler
2016-10-07 21:31 ` [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8 Tyler Baicar
2016-10-12 18:00 ` Punit Agrawal
2016-10-13 14:03 ` Baicar, Tyler
2016-10-14 9:39 ` Punit Agrawal
2016-10-18 12:44 ` Hanjun Guo
2016-10-19 16:59 ` Abdulhamid, Harb
2016-10-23 9:13 ` Hanjun Guo
2016-10-18 13:04 ` Hanjun Guo
2016-10-19 17:12 ` Abdulhamid, Harb
2016-10-07 21:31 ` [PATCH V3 06/10] acpi: apei: panic OS with fatal error status block Tyler Baicar
2016-10-13 13:00 ` Suzuki K Poulose [this message]
2016-10-13 23:34 ` Baicar, Tyler
2016-10-07 21:31 ` [PATCH V3 07/10] efi: print unrecognized CPER section Tyler Baicar
2016-10-07 21:31 ` [PATCH V3 08/10] ras: acpi / apei: generate trace event for " Tyler Baicar
2016-10-13 10:54 ` Punit Agrawal
2016-10-13 20:15 ` Baicar, Tyler
2016-10-07 21:31 ` [PATCH V3 09/10] trace, ras: add ARM processor error trace event Tyler Baicar
2016-10-07 21:39 ` Steven Rostedt
2016-10-12 21:23 ` Baicar, Tyler
2016-10-07 21:31 ` [PATCH V3 10/10] arm64: KVM: add guest SEA support Tyler Baicar
2016-10-13 13:14 ` Punit Agrawal
2016-10-13 20:14 ` Baicar, Tyler
2016-10-14 9:38 ` Punit Agrawal
2016-10-14 21:58 ` Baicar, Tyler
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=bf911628-71be-0dca-f1c7-c12e681bd37f@arm.com \
--to=suzuki.poulose@arm.com \
--cc=Dkvm@vger.kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bristot@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=devel@acpica.org \
--cc=fu.wei@linaro.org \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=matt@codeblueprint.co.uk \
--cc=paul.gortmaker@windriver.com \
--cc=pbonzini@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=rkrcmar@redhat.com \
--cc=robert.moore@intel.com \
--cc=rostedt@goodmis.org \
--cc=sandeepa.s.prabhu@gmail.com \
--cc=shijie.huang@arm.com \
--cc=tbaicar@codeaurora.org \
--cc=tomasz.nowicki@linaro.org \
--cc=will.deacon@arm.com \
--cc=zjzhang@codeaurora.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
all inboxes | Powered by JetHome®