From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morse Subject: [PATCH v3 03/12] ACPI / APEI: don't wait to serialise with oops messages when panic()ing Date: Fri, 27 Apr 2018 16:35:01 +0100 Message-ID: <20180427153510.5799-4-james.morse@arm.com> References: <20180427153510.5799-1-james.morse@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CC8D94A09E for ; Fri, 27 Apr 2018 11:29:21 -0400 (EDT) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZ2WQ54FW+U4 for ; Fri, 27 Apr 2018 11:28:59 -0400 (EDT) Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BD7FE4A040 for ; Fri, 27 Apr 2018 11:28:59 -0400 (EDT) In-Reply-To: <20180427153510.5799-1-james.morse@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: linux-acpi@vger.kernel.org Cc: jonathan.zhang@cavium.com, Rafael Wysocki , Tony Luck , Christoffer Dall , Punit Agrawal , Marc Zyngier , Catalin Marinas , Tyler Baicar , Will Deacon , Dongjiu Geng , linux-mm@kvack.org, Borislav Petkov , Naoya Horiguchi , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Len Brown List-Id: kvmarm@lists.cs.columbia.edu oops_begin() exists to group printk() messages with the oops message printed by die(). To reach this caller we know that platform firmware took this error first, then notified the OS via NMI with a 'panic' severity. Don't wait for another CPU to release the die-lock before we can panic(), our only goal is to print this fatal error and panic(). This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi: generic solution for safe printk in NMI"), it has been safe to call printk() from this context. Messages are batched in a per-cpu buffer and printed via irq-work, or a call back from panic(). Link: https://patchwork.kernel.org/patch/10313555/ Acked-by: Borislav Petkov Signed-off-by: James Morse --- drivers/acpi/apei/ghes.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index c8a6c5b0516e..ed8ad9898365 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include @@ -758,9 +757,6 @@ static int _in_nmi_notify_one(struct ghes *ghes) sev = ghes_severity(ghes->estatus->error_severity); if (sev >= GHES_SEV_PANIC) { -#ifdef CONFIG_X86 - oops_begin(); -#endif ghes_print_queued_estatus(); __ghes_panic(ghes); } -- 2.16.2 From mboxrd@z Thu Jan 1 00:00:00 1970 From: james.morse@arm.com (James Morse) Date: Fri, 27 Apr 2018 16:35:01 +0100 Subject: [PATCH v3 03/12] ACPI / APEI: don't wait to serialise with oops messages when panic()ing In-Reply-To: <20180427153510.5799-1-james.morse@arm.com> References: <20180427153510.5799-1-james.morse@arm.com> Message-ID: <20180427153510.5799-4-james.morse@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org oops_begin() exists to group printk() messages with the oops message printed by die(). To reach this caller we know that platform firmware took this error first, then notified the OS via NMI with a 'panic' severity. Don't wait for another CPU to release the die-lock before we can panic(), our only goal is to print this fatal error and panic(). This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi: generic solution for safe printk in NMI"), it has been safe to call printk() from this context. Messages are batched in a per-cpu buffer and printed via irq-work, or a call back from panic(). Link: https://patchwork.kernel.org/patch/10313555/ Acked-by: Borislav Petkov Signed-off-by: James Morse --- drivers/acpi/apei/ghes.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index c8a6c5b0516e..ed8ad9898365 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include @@ -758,9 +757,6 @@ static int _in_nmi_notify_one(struct ghes *ghes) sev = ghes_severity(ghes->estatus->error_severity); if (sev >= GHES_SEV_PANIC) { -#ifdef CONFIG_X86 - oops_begin(); -#endif ghes_print_queued_estatus(); __ghes_panic(ghes); } -- 2.16.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 56F646B0008 for ; Fri, 27 Apr 2018 11:38:31 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id x192-v6so1252879oix.2 for ; Fri, 27 Apr 2018 08:38:31 -0700 (PDT) Received: from foss.arm.com (foss.arm.com. [217.140.101.70]) by mx.google.com with ESMTP id v13-v6si585779ota.230.2018.04.27.08.38.30 for ; Fri, 27 Apr 2018 08:38:30 -0700 (PDT) From: James Morse Subject: [PATCH v3 03/12] ACPI / APEI: don't wait to serialise with oops messages when panic()ing Date: Fri, 27 Apr 2018 16:35:01 +0100 Message-Id: <20180427153510.5799-4-james.morse@arm.com> In-Reply-To: <20180427153510.5799-1-james.morse@arm.com> References: <20180427153510.5799-1-james.morse@arm.com> Sender: owner-linux-mm@kvack.org List-ID: To: linux-acpi@vger.kernel.org Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, Borislav Petkov , Marc Zyngier , Christoffer Dall , Will Deacon , Catalin Marinas , Naoya Horiguchi , Rafael Wysocki , Len Brown , Tony Luck , Tyler Baicar , Dongjiu Geng , Xie XiuQi , Punit Agrawal , jonathan.zhang@cavium.com, James Morse oops_begin() exists to group printk() messages with the oops message printed by die(). To reach this caller we know that platform firmware took this error first, then notified the OS via NMI with a 'panic' severity. Don't wait for another CPU to release the die-lock before we can panic(), our only goal is to print this fatal error and panic(). This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi: generic solution for safe printk in NMI"), it has been safe to call printk() from this context. Messages are batched in a per-cpu buffer and printed via irq-work, or a call back from panic(). Link: https://patchwork.kernel.org/patch/10313555/ Acked-by: Borislav Petkov Signed-off-by: James Morse --- drivers/acpi/apei/ghes.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index c8a6c5b0516e..ed8ad9898365 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include @@ -758,9 +757,6 @@ static int _in_nmi_notify_one(struct ghes *ghes) sev = ghes_severity(ghes->estatus->error_severity); if (sev >= GHES_SEV_PANIC) { -#ifdef CONFIG_X86 - oops_begin(); -#endif ghes_print_queued_estatus(); __ghes_panic(ghes); } -- 2.16.2