Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2861048pxj; Mon, 14 Jun 2021 08:47:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNODiOr7zVfavk468jjDhrKNexMcOWJpSnHOTg4R4D99P65EocKaZPpVnueBBxrNTKEZwA X-Received: by 2002:a17:907:abc:: with SMTP id bz28mr15999800ejc.446.1623685675631; Mon, 14 Jun 2021 08:47:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623685675; cv=none; d=google.com; s=arc-20160816; b=bSwSwTJbKqIG6vg4eoRt6uJA5xQVA3pyGEV4fMc1j1gxEGdgMoD6jFWzJXjBRFBA2n +4awLjT4mTW3XoNMS/rUj3SIngX5fXMzBdqUp15CHRDaeuggJ8KF69dwxiXF5LE2A57O RFfBosy3Qbu0h3aF37IhY13kG9eFjAu5Hj1YzL7WHa3Q9rDnHMNpmCP/d/qn+GJxegmi v1fdCDfHz2z8lD5pB1XiQeMHwHxJEgMYIxu85hDzbYxwOmrahRmpzxnRnYlx/GsUuowd Hi0Kh3D2oLmrFbSshp3IQdb9QyQTm5KAYM/rMs56rv5Vix+Gmn0Xnab9Fd/ILFDwgi9M qo9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=toPUT2S1k5OdAiBpsMpdY9PJGsGmpvlDZZQEqj7J4K8=; b=MxL9gQ8XLgXP+zxgApKTFJCoUxiekhuffzyFC9lXYjp+9QsaeM/A0Ssi3kEQMle5Az aecJh+d6wQxZllUPP4T02eg0VxACLUrH6Ij8YGl7XkNplVHdCjEu/oM++xJ2ZIZdgG1Q JOWXsMlse1Q1OY29ODh7QQab1MZqTKSHy4VEO6bzGEHTSec7g6c2HEmIuR93zKlaNBOV kH22ZcnP1wAO6oXohVCzsBV5Z6K1+Tyj/FbUXYUC+r5JjmPHAoC347Omb4y/IeMzCX/M aXoEDz+EtKJqo4NPOipOk5PPgBLdq+2yjUWqHVeq/oAsFS8ij4/uTVJpZM/NlruwmeOA 4O1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by10si11049913ejc.493.2021.06.14.08.47.33; Mon, 14 Jun 2021 08:47:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234121AbhFNPsV (ORCPT + 99 others); Mon, 14 Jun 2021 11:48:21 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:34337 "EHLO mail-ot1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233985AbhFNPsS (ORCPT ); Mon, 14 Jun 2021 11:48:18 -0400 Received: by mail-ot1-f50.google.com with SMTP id w22-20020a0568304116b02904060c6415c7so8909346ott.1; Mon, 14 Jun 2021 08:46:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=toPUT2S1k5OdAiBpsMpdY9PJGsGmpvlDZZQEqj7J4K8=; b=UN44xwqWVaSLArQynXoiLhaKpdZWAejrpxOhMrunmOoESvGtUN72UGT/ukBmJdjwvb CtrLTRlMwHp7Ewgwua1t+DpQquZIsf8Jkl+UMlj85tNXE/NqPbZK8EfyJc+vaYeaLlxQ xxhUTK+OhWAWVSYSTrM9TMFC0ByctyoVLu7537KL8cHt/5qtfvtZbE2y2n/AGEdgZRnZ 98W1+YxYj2ZHONAX8b0WSDBFx7+yVGqI10MdHXBzeTuTQMV8J0zejJQsGpOMqp7slp2q rO2uQq5rF0c40li5fl7/mqZo7ADUCoJcCW8nZnGJZB47FPqtFIUfYGlt+R4Q6URtPp+7 /S1Q== X-Gm-Message-State: AOAM531Tx6LCKmD/KHghDQyaRhCZrXvaH1vXXUwgbklXMU93/1o6JdlP 4Ad8USwuEfZcIdMLZBthNZhufAMVRnJAOniG8Cw= X-Received: by 2002:a05:6830:1bf7:: with SMTP id k23mr14381825otb.206.1623685575508; Mon, 14 Jun 2021 08:46:15 -0700 (PDT) MIME-Version: 1.0 References: <1623415027-36130-1-git-send-email-tanxiaofei@huawei.com> In-Reply-To: <1623415027-36130-1-git-send-email-tanxiaofei@huawei.com> From: "Rafael J. Wysocki" Date: Mon, 14 Jun 2021 17:46:04 +0200 Message-ID: Subject: Re: [PATCH v7] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode To: Xiaofei Tan , James Morse Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , Tony Luck , Borislav Petkov , Andrew Morton , Joerg Roedel , Peter Zijlstra , ACPI Devel Maling List , Linux Kernel Mailing List , linuxarm@openeuler.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 11, 2021 at 2:40 PM Xiaofei Tan wrote: > > Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() > synchronise with APEI's irq work"), do_sea() would unconditionally > signal the affected task from the arch code. Since that change, > the GHES driver sends the signals. > > This exposes a problem as errors the GHES driver doesn't understand > or doesn't handle effectively are silently ignored. It will cause > the errors get taken again, and circulate endlessly. User-space task > get stuck in this loop. > > Existing firmware on Kunpeng9xx systems reports cache errors with the > 'ARM Processor Error' CPER records. > > Do memory failure handling for ARM Processor Error Section just like > for Memory Error Section. Still, I'm not convinced that this is the right way to address the problem. In particular, is it guaranteed that "ARM Processor Error" will always mean "memory failure" on all platforms? If not, doing a platform-specific quirk might be better. James, I need you to hear from you here I suppose. > Fixes: 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work") > Signed-off-by: Xiaofei Tan > Reviewed-by: James Morse > > --- > Changes since v5: > - Do some changes following James's suggestions: 1) optimize commit log > 2) use err_info->length instead of err_info++' 3) some coding style > advice. > > Changes since v4: > - 1. Change the patch name from " ACPI / APEI: do memory failure on the > physical address reported by ARM processor error section" to this > more proper one. > - 2. Add a comment in the code to tell why not filter out corrected > error in an uncorrected section. > > Changes since v3: > - Print unhandled error following James Morse's advice. > > Changes since v2: > - Updated commit log > --- > drivers/acpi/apei/ghes.c | 81 ++++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 64 insertions(+), 17 deletions(-) > > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > index fce7ade..0c8330e 100644 > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -441,28 +441,35 @@ static void ghes_kick_task_work(struct callback_head *head) > gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len); > } > > -static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, > - int sev) > +static bool ghes_do_memory_failure(u64 physical_addr, int flags) > { > unsigned long pfn; > - int flags = -1; > - int sec_sev = ghes_severity(gdata->error_severity); > - struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); > > if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) > return false; > > - if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) > - return false; > - > - pfn = mem_err->physical_addr >> PAGE_SHIFT; > + pfn = PHYS_PFN(physical_addr); > if (!pfn_valid(pfn)) { > pr_warn_ratelimited(FW_WARN GHES_PFX > "Invalid address in generic error data: %#llx\n", > - mem_err->physical_addr); > + physical_addr); > return false; > } > > + memory_failure_queue(pfn, flags); > + return true; > +} > + > +static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, > + int sev) > +{ > + int flags = -1; > + int sec_sev = ghes_severity(gdata->error_severity); > + struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); > + > + if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) > + return false; > + > /* iff following two events can be handled properly by now */ > if (sec_sev == GHES_SEV_CORRECTED && > (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) > @@ -470,14 +477,56 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, > if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) > flags = 0; > > - if (flags != -1) { > - memory_failure_queue(pfn, flags); > - return true; > - } > + if (flags != -1) > + return ghes_do_memory_failure(mem_err->physical_addr, flags); > > return false; > } > > +static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev) > +{ > + struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); > + bool queued = false; > + int sec_sev, i; > + char *p; > + > + log_arm_hw_error(err); > + > + sec_sev = ghes_severity(gdata->error_severity); > + if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE) > + return false; > + > + p = (char *)(err + 1); > + for (i = 0; i < err->err_info_num; i++) { > + struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; > + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); > + bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); > + const char *error_type = "unknown error"; > + > + /* > + * The field (err_info->error_info & BIT(26)) is fixed to set to > + * 1 in some old firmware of HiSilicon Kunpeng920. We assume that > + * firmware won't mix corrected errors in an uncorrected section, > + * and don't filter out 'corrected' error here. > + */ > + if (is_cache && has_pa) { > + queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0); > + p += err_info->length; > + continue; > + } > + > + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) > + error_type = cper_proc_error_type_strs[err_info->type]; > + > + pr_warn_ratelimited(FW_WARN GHES_PFX > + "Unhandled processor error type: %s\n", > + error_type); > + p += err_info->length; > + } > + > + return queued; > +} > + > /* > * PCIe AER errors need to be sent to the AER driver for reporting and > * recovery. The GHES severities map to the following AER severities and > @@ -605,9 +654,7 @@ static bool ghes_do_proc(struct ghes *ghes, > ghes_handle_aer(gdata); > } > else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) { > - struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); > - > - log_arm_hw_error(err); > + queued = ghes_handle_arm_hw_error(gdata, sev); > } else { > void *err = acpi_hest_get_payload(gdata); > > -- > 2.8.1 >