From patchwork Mon May 14 14:59:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Alex G." X-Patchwork-Id: 10398659 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C3A52600D0 for ; Mon, 14 May 2018 15:00:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B35D5280FC for ; Mon, 14 May 2018 15:00:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B15FA28385; Mon, 14 May 2018 15:00:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 553B5281D2 for ; Mon, 14 May 2018 15:00:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754256AbeENPAG (ORCPT ); Mon, 14 May 2018 11:00:06 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:55503 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754251AbeENPAD (ORCPT ); Mon, 14 May 2018 11:00:03 -0400 Received: by mail-it0-f67.google.com with SMTP id 144-v6so10950509iti.5; Mon, 14 May 2018 08:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=t010076FCGWaaa1OE9JaYjOwYI/k0kYrpG6vyjGTlmQ=; b=o7OmkRyhKKWBAvZR9jdb/fWS7VcuQG7dVF/XtT7qWvO1ObwFh6Z/3jsDRe5uy3eQbC FYhj+UqHvG9B3+U+SVDYw1VksiuqNbWFnfQ1olXbGhHCmEOR5qi0jpXUlQRg1w0RXAiB eg/Hkd9KkZisj9oWEoXIDvkK0egTpjZ2i3Az7mYv1881emdbH1HVYaW6Y7qzISpC888q ed79Un1UXw/w79IkJtZArzItzeTLXcx8jCQ0uIGmHg+b/RODf7NW5C85nv9jamSsADgP fdqzxixRsWnvcNk4syilfwpkypxMaFqZ8WFlN+kqvOIsTCrZqXgme8tzKbe8/62ZhKtD Poew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=t010076FCGWaaa1OE9JaYjOwYI/k0kYrpG6vyjGTlmQ=; b=aZY9IVF6jkP1OiDfQ7vuI4dOULlfbS9bAu0ruu1hbvInwTAXgh2jpOSOCWGhzIb8aN bXoXWYoLL2lrA3fomdqtEqpMVtC7L2Jp1Uk7CjJf2q5WSrfk6ZGgEo4AAoOxQcsDjI+B LrwOSQwTyfVpLrBHsG8ZHmPEhBZyCIjATEXAzFMjQyvVALafz9x+YSRnDh+kA4PGlpBy OsrMLS0o8XVWbkbp/+9VHRegY3YWfzfZLHmO89qWhVcmhXa5bHHsOytO6UZ1LSoCSqQQ Qh5e5w0pNRugLs3qEit0Kk9JK3TM5aGHTuXJuOkdlmGR1brQmBzQLmhgZDMBz13el94U u2WQ== X-Gm-Message-State: ALKqPwd4OzQx6NbxXT3mXgFpzSPwlDFUCm2+ZOTb/rr+MlUFXuTIrHuw SPJhy8JLCBzfYII5aAHKwZk= X-Google-Smtp-Source: AB8JxZpWoHUtnqZ+fS9tyEwlHO1E1IjYDqtM8jtvLjmJTlLROex+p2MtDORno/a7yfMxVIG9WegnHA== X-Received: by 2002:a24:4c55:: with SMTP id a82-v6mr9718046itb.1.1526310002375; Mon, 14 May 2018 08:00:02 -0700 (PDT) Received: from nuclearis2_1.lan (c-98-201-114-184.hsd1.tx.comcast.net. [98.201.114.184]) by smtp.gmail.com with ESMTPSA id y14-v6sm4653715ioc.52.2018.05.14.08.00.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 14 May 2018 08:00:01 -0700 (PDT) From: Alexandru Gagniuc To: bp@alien8.de Cc: alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, Alexandru Gagniuc , "Rafael J. Wysocki" , Len Brown , Tony Luck , Tyler Baicar , Will Deacon , James Morse , Shiju Jose , "Jonathan (Zhixiong) Zhang" , Dongjiu Geng , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 2/2] acpi: apei: Do not panic() on PCIe errors reported through GHES Date: Mon, 14 May 2018 09:59:29 -0500 Message-Id: <20180514145933.10291-3-mr.nuke.me@gmail.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180514145933.10291-1-mr.nuke.me@gmail.com> References: <20180430212836.7807-1-mr.nuke.me@gmail.com> <20180514145933.10291-1-mr.nuke.me@gmail.com> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The policy was to panic() when GHES said that an error is "Fatal". This logic is wrong for several reasons, as it doesn't take into account what caused the error. PCIe fatal errors indicate that the link to a device is either unstable or unusable. They don't indicate that the machine is on fire, and they are not severe enough that we need to panic(). Instead of relying on crackmonkey firmware, evaluate the error severity based on what caused the error (GHES subsections). Signed-off-by: Alexandru Gagniuc --- drivers/acpi/apei/ghes.c | 48 +++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 7c1a16b106ba..9baaab798020 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -425,8 +425,7 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int * GHES_SEV_RECOVERABLE -> AER_NONFATAL * GHES_SEV_RECOVERABLE && CPER_SEC_RESET -> AER_FATAL * These both need to be reported and recovered from by the AER driver. - * GHES_SEV_PANIC does not make it to this handling since the kernel must - * panic. + * GHES_SEV_PANIC -> AER_FATAL */ static void ghes_handle_aer(struct acpi_hest_generic_data *gdata) { @@ -459,6 +458,49 @@ static void ghes_handle_aer(struct acpi_hest_generic_data *gdata) #endif } +/* PCIe errors should not cause a panic. */ +static int ghes_sec_pcie_severity(struct acpi_hest_generic_data *gdata) +{ + struct cper_sec_pcie *pcie_err = acpi_hest_get_payload(gdata); + + if (pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID && + pcie_err->validation_bits & CPER_PCIE_VALID_AER_INFO && + IS_ENABLED(CONFIG_ACPI_APEI_PCIEAER)) + return GHES_SEV_RECOVERABLE; + + return ghes_cper_severity(gdata->error_severity); +} + +/* + * The severity field in the status block is an unreliable metric for the + * severity. A more reliable way is to look at each subsection and see how safe + * it is to call the approproate error handler. + * We're not conerned with handling the error. We're concerned with being able + * to notify an error handler by crossing the NMI/IRQ boundary, being able to + * schedule_work, and so forth. + * - SEC_PCIE: All PCIe errors can be handled by AER. + */ +static int ghes_severity(struct ghes *ghes) +{ + int worst_sev, sec_sev; + struct acpi_hest_generic_data *gdata; + const guid_t *section_type; + const struct acpi_hest_generic_status *estatus = ghes->estatus; + + worst_sev = GHES_SEV_NO; + apei_estatus_for_each_section(estatus, gdata) { + section_type = (guid_t *)gdata->section_type; + sec_sev = ghes_cper_severity(gdata->error_severity); + + if (guid_equal(section_type, &CPER_SEC_PCIE)) + sec_sev = ghes_sec_pcie_severity(gdata); + + worst_sev = max(worst_sev, sec_sev); + } + + return worst_sev; +} + static void ghes_do_proc(struct ghes *ghes, const struct acpi_hest_generic_status *estatus) { @@ -944,7 +986,7 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs) ret = NMI_HANDLED; } - sev = ghes_cper_severity(ghes->estatus->error_severity); + sev = ghes_severity(ghes); if (sev >= GHES_SEV_PANIC) { oops_begin(); ghes_print_queued_estatus();