From patchwork Mon May 21 13:49:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Alex G." X-Patchwork-Id: 10415389 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 7B5AD60365 for ; Mon, 21 May 2018 13:51:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 68B8728917 for ; Mon, 21 May 2018 13:51:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5CE0B28915; Mon, 21 May 2018 13:51:15 +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 E26F528917 for ; Mon, 21 May 2018 13:51:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752869AbeEUNua (ORCPT ); Mon, 21 May 2018 09:50:30 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:53034 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752862AbeEUNu0 (ORCPT ); Mon, 21 May 2018 09:50:26 -0400 Received: by mail-it0-f68.google.com with SMTP id y189-v6so21110013itb.2; Mon, 21 May 2018 06:50:25 -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=6Z+4esjc7vkBmeWhBKWiNTk8fdhqsGX65tdfyi40Z6w=; b=SbB0ZpthnfvKK4afdy0obXRsYTCV1W5ITVZZBLFAU1TwdwKpWwztCV8/SWNL/cnBTp fIJphhxcZ1bBeeHyC9hkyPX3v1Vfk5RzF9cn/0BsQYYKXXQMhkZOmktDrf0cToq8tVpx noFjkCpM04WnNZohgI4t8OBOBxC63EFmM5olsCMdI9p9eUnqkKAJcD63fIsajBMIlu2T oZRwpJzINSo8GQdm4qK5N4nyxsWucHPicsDYzIhBhkBhA15K+RyUoi7PccM1HpaQhn6+ pqwzrAsQmEP8fipeFOmZuqPic2vHBDN4ufmhIFAFRlROYNKItj3YzOtUx5l14fr9ipl6 b4MA== 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=6Z+4esjc7vkBmeWhBKWiNTk8fdhqsGX65tdfyi40Z6w=; b=eWGE7M0117VwdgkK1BS994QFybQejmxcdqBO2eeNsKyvBPSXoxfEY9lp/jzvCQOmfK w8BArYjQlo8KSc5HWhsnkki19pjDVoo1AvIWlh2VtMlfahceR+qC30VevCKofP+fygJm WJkzzo6HLPa9vOELu9+BUUkVlIjcH6Xe9pqreEYL/rJZQmmXQIfxGc8hz9OGMc+ExZYk cVnCkaCMLxQcDOcC2ZYbimqg+l4tYHKUsrbBwfB/REVPi5ds7GQtqqCQ9w3slN3xHv8l 6qdujgyPXOcb7Sc3faUR9EXiC46LnuyQq9BXSCSWKLtE4Zj1R3hK6uweEra5w91YZIqN Z4HA== X-Gm-Message-State: ALKqPwcYnfcl8qI5m3gUXA58xCQ+MPr+g/Dy3TWeiRhssVzJVchCryeN D4U2vK/J/LZ4Xtt7pBHd5ug= X-Google-Smtp-Source: AB8JxZoM4ml2BmiLL3mI+ebWhxY/s0enClq6T9w3VUrOfFVA5VsxNmEqMNvK1i0aoJptZWXyxV+rgw== X-Received: by 2002:a24:2c93:: with SMTP id i141-v6mr18634539iti.72.1526910625233; Mon, 21 May 2018 06:50:25 -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 f4-v6sm8432212itf.22.2018.05.21.06.50.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 May 2018 06:50:24 -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 v6 2/2] acpi: apei: Do not panic() on PCIe errors reported through GHES Date: Mon, 21 May 2018 08:49:59 -0500 Message-Id: <20180521135003.32459-3-mr.nuke.me@gmail.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180521135003.32459-1-mr.nuke.me@gmail.com> References: <20180521135003.32459-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 account for the cause of 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 to justify a panic(). Do not blindly rely on firmware to evaluate the severity for us. Instead, look at 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();