Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4623162imm; Mon, 14 May 2018 10:07:08 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqPPdBuGt9W/tZihoeve2Uro7D9EzEt+H9zEBDK66LK9jpDmTjwk9qhNAIriaeL7IuAjUik X-Received: by 2002:a63:6f4c:: with SMTP id k73-v6mr1672771pgc.303.1526317628103; Mon, 14 May 2018 10:07:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526317628; cv=none; d=google.com; s=arc-20160816; b=VFqw/ObnAUfH34Eyr3nISWF3msLrU+7ucg/m+4qgcvm7BviR9mmJSatdtNt4RSX8FG +F0+PyPGjppC8REV2Iuby06odxq+k0HAZ3KOjevYntHF8uIcXjAS2ZRCrWqOHvdREw1Y 6eHK7yRZl/WRhwe78TG8JgAIh4zU0s+aVHTxel6+V3eOuYH0ozmtW9NziyhQLpMDXkh9 wOpErr0VOYbk71LRXJWmXZ9wYcgEBMfddf++FsmyzB0iJEngsn5puYX3BQZ6c1KGWMSz UOYGbEGN4SswEZfQ1RCSHzoJyNMxV6mP762LUjT39NyNf4pd26CJ8i3k+LqI704dMjMG ihCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=t010076FCGWaaa1OE9JaYjOwYI/k0kYrpG6vyjGTlmQ=; b=pTMbSh9CD/gWKUdsvl7kRxoFCXAe6XES6ytyN0IgGOYXUvr46i5Vy9hppP6wSUVgVx 7Sgvta7adp9JJ6pXbUQl9EGZxE+EM3VkNhsqb60vGkWUfUGN9QTujSRhRYBpLShsjgyP vk5AW2oKvb+GApYbhzEwj/7GMzhJHCndumlTQu3nmkdcbGnIfE8hvCJtvHxAkIy67N7F VOQtfUFSjOWehAaOKSU6opXdww/APEWpCtUT/DYTMzlklfPlJXgsHn6qrgpERil7HMOr JdJHlOATRRFH+8y2DJ5HOtXtGMXIMlL8Q4k7/Ai+uxv1unnJUQwOcVRqMC+HvR2c7Y19 K5wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o7OmkRyh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i64-v6si9823951pli.274.2018.05.14.10.06.50; Mon, 14 May 2018 10:07:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o7OmkRyh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754267AbeENPAG (ORCPT + 99 others); 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-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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(); -- 2.14.3