linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shuai Xue <xueshuai@linux.alibaba.com>
To: tanxiaofei@huawei.com, mawupeng1@huawei.com, tony.luck@intel.com,
	naoya.horiguchi@nec.com
Cc: linux-acpi@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, xueshuai@linux.alibaba.com,
	justin.he@arm.com, akpm@linux-foundation.org, ardb@kernel.org,
	ashish.kalra@amd.com, baolin.wang@linux.alibaba.com,
	bp@alien8.de, cuibixuan@linux.alibaba.com,
	dave.hansen@linux.intel.com, james.morse@arm.com,
	jarkko@kernel.org, lenb@kernel.org, linmiaohe@huawei.com,
	lvying6@huawei.com, rafael@kernel.org, xiexiuqi@huawei.com,
	zhuo.song@linux.alibaba.com
Subject: [PATCH v4 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
Date: Sat,  8 Apr 2023 17:13:58 +0800	[thread overview]
Message-ID: <20230408091359.31554-2-xueshuai@linux.alibaba.com> (raw)
In-Reply-To: <20221027042445.60108-1-xueshuai@linux.alibaba.com>

There are two major types of uncorrected recoverable (UCR) errors :

- Action Required (AR): The error is detected and the processor already
  consumes the memory. OS requires to take action (for example, offline
  failure page/kill failure thread) to recover this uncorrectable error.

- Action Optional (AO): The error is detected out of processor execution
  context. Some data in the memory are corrupted. But the data have not
  been consumed. OS is optional to take action to recover this
  uncorrectable error.

The essential difference between AR and AO errors is that AR is a
synchronous event, while AO is an asynchronous event. The hardware will
signal a synchronous exception (Machine Check Exception on X86 and
Synchronous External Abort on Arm64) when an error is detected and the
memory access has been architecturally executed.

When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For AR errors, kernel will kill current process
accessing the poisoned page by sending SIGBUS with BUS_MCEERR_AR. In
addition, for AO errors, kernel will notify the process who owns the
poisoned page by sending SIGBUS with BUS_MCEERR_AO in early kill mode.
However, the GHES driver always sets mf_flags to 0 so that all UCR errors
are handled as AO errors in memory failure.

To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.

Fixes: ba61ca4aab47 ("ACPI, APEI, GHES: Add hardware memory error recovery support")'
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
---
 drivers/acpi/apei/ghes.c | 29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 34ad071a64e9..c479b85899f5 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -101,6 +101,20 @@ static inline bool is_hest_type_generic_v2(struct ghes *ghes)
 	return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
 }
 
+/*
+ * A platform may describe one error source for the handling of synchronous
+ * errors (e.g. MCE or SEA), or for handling asynchronous errors (e.g. SCI
+ * or External Interrupt). On x86, the HEST notifications are always
+ * asynchronous, so only SEA on ARM is delivered as a synchronous
+ * notification.
+ */
+static inline bool is_hest_sync_notify(struct ghes *ghes)
+{
+	u8 notify_type = ghes->generic->notify.type;
+
+	return notify_type == ACPI_HEST_NOTIFY_SEA;
+}
+
 /*
  * This driver isn't really modular, however for the time being,
  * continuing to use module_param is the easiest way to remain
@@ -477,7 +491,7 @@ static bool ghes_do_memory_failure(u64 physical_addr, int flags)
 }
 
 static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
-				       int sev)
+				       int sev, bool sync)
 {
 	int flags = -1;
 	int sec_sev = ghes_severity(gdata->error_severity);
@@ -491,7 +505,7 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
 	    (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED))
 		flags = MF_SOFT_OFFLINE;
 	if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE)
-		flags = 0;
+		flags = sync ? MF_ACTION_REQUIRED : 0;
 
 	if (flags != -1)
 		return ghes_do_memory_failure(mem_err->physical_addr, flags);
@@ -499,9 +513,11 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
 	return false;
 }
 
-static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev)
+static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
+				       int sev, bool sync)
 {
 	struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
+	int flags = sync ? MF_ACTION_REQUIRED : 0;
 	bool queued = false;
 	int sec_sev, i;
 	char *p;
@@ -526,7 +542,7 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int s
 		 * and don't filter out 'corrected' error here.
 		 */
 		if (is_cache && has_pa) {
-			queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0);
+			queued = ghes_do_memory_failure(err_info->physical_fault_addr, flags);
 			p += err_info->length;
 			continue;
 		}
@@ -647,6 +663,7 @@ static bool ghes_do_proc(struct ghes *ghes,
 	const guid_t *fru_id = &guid_null;
 	char *fru_text = "";
 	bool queued = false;
+	bool sync = is_hest_sync_notify(ghes);
 
 	sev = ghes_severity(estatus->error_severity);
 	apei_estatus_for_each_section(estatus, gdata) {
@@ -664,13 +681,13 @@ static bool ghes_do_proc(struct ghes *ghes,
 			atomic_notifier_call_chain(&ghes_report_chain, sev, mem_err);
 
 			arch_apei_report_mem_error(sev, mem_err);
-			queued = ghes_handle_memory_failure(gdata, sev);
+			queued = ghes_handle_memory_failure(gdata, sev, sync);
 		}
 		else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
 			ghes_handle_aer(gdata);
 		}
 		else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
-			queued = ghes_handle_arm_hw_error(gdata, sev);
+			queued = ghes_handle_arm_hw_error(gdata, sev, sync);
 		} else {
 			void *err = acpi_hest_get_payload(gdata);
 
-- 
2.20.1.12.g72788fdb


  parent reply	other threads:[~2023-04-08  9:14 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27  4:24 [PATCH] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on action required events Shuai Xue
2022-10-28 17:08 ` Rafael J. Wysocki
2022-10-28 17:25   ` Luck, Tony
2022-11-02 11:53     ` Shuai Xue
2022-11-22 11:40       ` Shuai Xue
2022-11-02  7:07   ` Shuai Xue
2022-12-06 15:33 ` [RFC PATCH 0/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2022-12-07  9:54   ` reply for " Lv Ying
2022-12-07 12:34     ` Bixuan Cui
2022-12-07 12:56     ` Shuai Xue
2022-12-07 14:04       ` Shuai Xue
2022-12-08  2:27         ` Lv Ying
2022-12-06 15:33 ` [RFC PATCH 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2022-12-06 15:33 ` [RFC PATCH 2/2] ACPI: APEI: separate synchronous error handling into task work Shuai Xue
2023-02-27  5:03 ` [PATCH v2 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code Shuai Xue
2023-03-06  0:45   ` Shuai Xue
2023-02-27  5:03 ` [PATCH v2 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-03-16  7:21   ` HORIGUCHI NAOYA(堀口 直也)
2023-03-16  9:57     ` Shuai Xue
2023-03-16 16:45       ` Luck, Tony
2023-03-17  1:12         ` Shuai Xue
2023-02-27  5:03 ` [PATCH v2 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-03-16  7:21   ` HORIGUCHI NAOYA(堀口 直也)
2023-03-16 11:10     ` Shuai Xue
2023-03-17  0:29       ` HORIGUCHI NAOYA(堀口 直也)
2023-03-17  1:24         ` Shuai Xue
2023-03-17  7:24 ` [PATCH v3 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code Shuai Xue
2023-03-20 18:03   ` Rafael J. Wysocki
2023-03-30  6:11     ` Shuai Xue
2023-03-30  9:52       ` Rafael J. Wysocki
2023-03-21  7:17   ` mawupeng
2023-03-22  1:27     ` Shuai Xue
2023-03-17  7:24 ` [PATCH v3 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-03-17  7:24 ` [PATCH v3 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-04-06 12:39   ` Xiaofei Tan
2023-04-07  2:21     ` Shuai Xue
2023-04-08  9:13 ` [PATCH v4 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code Shuai Xue
2023-04-08  9:13 ` Shuai Xue [this message]
2023-04-08  9:13 ` [PATCH v4 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-04-11  1:44   ` Xiaofei Tan
2023-04-11  3:16     ` Shuai Xue
2023-04-11  9:02       ` Xiaofei Tan
2023-04-11  9:48         ` Shuai Xue
2023-04-11 10:48 ` [PATCH v5 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code Shuai Xue
2023-04-11 10:48 ` [PATCH v5 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-04-11 14:17   ` Kefeng Wang
2023-04-12  2:54     ` Shuai Xue
2023-04-12  3:55   ` Xiaofei Tan
2023-04-13  1:42     ` Shuai Xue
2023-04-11 10:48 ` [PATCH v5 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-04-11 14:28   ` Kefeng Wang
2023-04-12  2:58     ` Shuai Xue
2023-04-12  4:05   ` Xiaofei Tan
2023-04-13  1:49     ` Shuai Xue
2023-04-12 11:27 ` [PATCH v6 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code Shuai Xue
2023-04-12 11:28 ` [PATCH v6 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-04-12 11:28 ` [PATCH v6 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-04-17  1:14 ` [PATCH v7 0/2] ACPI: APEI: handle synchronous exceptions with proper si_code Shuai Xue
2023-04-24  6:24   ` Shuai Xue
2023-05-08  1:55     ` Shuai Xue
2023-04-17  1:14 ` [PATCH v7 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-04-17  1:14 ` [PATCH v7 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-09-19  2:21 ` [RESEND PATCH v8 0/2] ACPI: APEI: handle synchronous errors in task work with proper si_code Shuai Xue
2023-09-19  2:21 ` [RESEND PATCH v8 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-09-25 14:43   ` Jarkko Sakkinen
2023-09-26  6:23     ` Shuai Xue
2023-09-19  2:21 ` [RESEND PATCH v8 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-09-25 15:00   ` Jarkko Sakkinen
2023-09-26  6:38     ` Shuai Xue
2023-10-03  8:28   ` Naoya Horiguchi
2023-10-07  2:01     ` Shuai Xue
2023-10-07  7:28 ` [PATCH v9 0/2] ACPI: APEI: handle synchronous errors in task work with proper si_code Shuai Xue
2023-11-21  1:48   ` Shuai Xue
2023-11-23 15:07   ` Borislav Petkov
2023-11-25  6:44     ` Shuai Xue
2023-11-25 12:10       ` Borislav Petkov
2023-11-26 12:25         ` Shuai Xue
2023-11-29 18:54           ` Borislav Petkov
2023-11-30  2:58             ` Shuai Xue
2023-11-30 14:40               ` Borislav Petkov
2023-11-30 17:43                 ` James Morse
2023-12-01  2:58                   ` Shuai Xue
2023-11-30 17:39             ` James Morse
2023-12-01  3:37               ` Shuai Xue
2023-10-07  7:28 ` [PATCH v9 1/2] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-11-30 17:39   ` James Morse
2023-12-01  5:22     ` Shuai Xue
2023-10-07  7:28 ` [PATCH v9 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-11-30 17:39   ` James Morse
2023-12-01  7:03     ` Shuai Xue
2023-12-18  6:45 ` [PATCH v10 0/4] ACPI: APEI: handle synchronous errors in task work with proper si_code Shuai Xue
2023-12-18  6:45 ` [PATCH v10 1/4] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events Shuai Xue
2023-12-18  6:53   ` Greg KH
2023-12-21 13:55   ` Rafael J. Wysocki
2023-12-22  1:07     ` Shuai Xue
2023-12-18  6:45 ` [PATCH v10 2/4] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered Shuai Xue
2023-12-18  6:54   ` Greg KH
2023-12-18  6:45 ` [PATCH v10 3/4] mm: memory-failure: move memory_failure() return value documentation to function declaration Shuai Xue
2023-12-18  6:54   ` Greg KH
2023-12-18  6:45 ` [PATCH v10 4/4] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2023-12-18  6:54   ` Greg KH
2024-02-04  8:01 ` [PATCH v11 0/3] ACPI: APEI: handle synchronous exceptions in task work to send correct SIGBUS si_code Shuai Xue
2024-02-19  1:46   ` Shuai Xue
2024-02-04  8:01 ` [PATCH v11 1/3] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered Shuai Xue
2024-02-19  9:25   ` Borislav Petkov
2024-02-22  2:07     ` Shuai Xue
2024-02-23  5:26       ` Dan Williams
2024-02-23 12:08         ` Jonathan Cameron
2024-02-23 12:17           ` Jonathan Cameron
2024-02-24  6:08             ` Shuai Xue
2024-02-26 10:29               ` Borislav Petkov
2024-02-27  1:23                 ` Shuai Xue
2024-02-24 19:42             ` Dan Williams
2024-02-24 19:40     ` Dan Williams
2024-02-04  8:01 ` [PATCH v11 2/3] mm: memory-failure: move return value documentation to function declaration Shuai Xue
2024-02-26 10:46   ` Borislav Petkov
2024-02-27  1:27     ` Shuai Xue
2024-02-04  8:01 ` [PATCH v11 3/3] ACPI: APEI: handle synchronous exceptions in task work to send correct SIGBUS si_code Shuai Xue
2024-02-29  7:05   ` Shuai Xue
2024-03-08 10:18   ` Borislav Petkov
2024-03-12  6:05     ` Shuai Xue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230408091359.31554-2-xueshuai@linux.alibaba.com \
    --to=xueshuai@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=ashish.kalra@amd.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bp@alien8.de \
    --cc=cuibixuan@linux.alibaba.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=james.morse@arm.com \
    --cc=jarkko@kernel.org \
    --cc=justin.he@arm.com \
    --cc=lenb@kernel.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lvying6@huawei.com \
    --cc=mawupeng1@huawei.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=rafael@kernel.org \
    --cc=tanxiaofei@huawei.com \
    --cc=tony.luck@intel.com \
    --cc=xiexiuqi@huawei.com \
    --cc=zhuo.song@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).