| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJZ5v0hnKP9S+5PfuO1EzvpSdHM09s0HidGjfinf491xkdop3g@mail.gmail.com>
Date: Thu, 21 Dec 2023 14:55:33 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Shuai Xue <xueshuai@...ux.alibaba.com>
Cc: bp@...en8.de, rafael@...nel.org, wangkefeng.wang@...wei.com,
tanxiaofei@...wei.com, mawupeng1@...wei.com, tony.luck@...el.com,
linmiaohe@...wei.com, naoya.horiguchi@....com, james.morse@....com,
gregkh@...uxfoundation.org, will@...nel.org, jarkko@...nel.org,
linux-acpi@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, linux-edac@...r.kernel.org,
acpica-devel@...ts.linuxfoundation.org, stable@...r.kernel.org,
x86@...nel.org, justin.he@....com, ardb@...nel.org, ying.huang@...el.com,
ashish.kalra@....com, baolin.wang@...ux.alibaba.com, tglx@...utronix.de,
mingo@...hat.com, dave.hansen@...ux.intel.com, lenb@...nel.org, hpa@...or.com,
robert.moore@...el.com, lvying6@...wei.com, xiexiuqi@...wei.com,
zhuo.song@...ux.alibaba.com
Subject: Re: [PATCH v10 1/4] ACPI: APEI: set memory failure flags as
MF_ACTION_REQUIRED on synchronous events
On Mon, Dec 18, 2023 at 7:45 AM Shuai Xue <xueshuai@...ux.alibaba.com> wrote:
>
> There are two major types of uncorrected recoverable (UCR) errors :
>
> - Synchronous error: The error is detected and raised at the point of the
> consumption in the execution flow, e.g. when a CPU tries to access
> a poisoned cache line. The CPU will take a synchronous error exception
> such as Synchronous External Abort (SEA) on Arm64 and Machine Check
> Exception (MCE) on X86. OS requires to take action (for example, offline
> failure page/kill failure thread) to recover this uncorrectable error.
>
> - Asynchronous error: The error is detected out of processor execution
> context, e.g. when an error is detected by a background scrubber. 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.
>
> 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 synchronous errors, kernel will kill the current
> process which accessing the poisoned page by sending SIGBUS with
> BUS_MCEERR_AR. In addition, for asynchronous 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 synchronous errors are handled as asynchronous errors in memory failure.
>
> To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
> events.
>
> Signed-off-by: Shuai Xue <xueshuai@...ux.alibaba.com>
> Tested-by: Ma Wupeng <mawupeng1@...wei.com>
> Reviewed-by: Kefeng Wang <wangkefeng.wang@...wei.com>
> Reviewed-by: Xiaofei Tan <tanxiaofei@...wei.com>
> Reviewed-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
> Reviewed-by: James Morse <james.morse@....com>
Applied as 6.8 material.
The other patches in the series still need to receive tags from the
APEI designated reviewers (as per MAINTAINERS).
Thanks!
> ---
> 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 63ad0541db38..ab2a82cb1b0b 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
> @@ -489,7 +503,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);
> @@ -503,7 +517,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);
> @@ -511,9 +525,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;
> @@ -538,7 +554,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;
> }
> @@ -666,6 +682,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) {
> @@ -683,13 +700,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.39.3
>
Powered by blists - more mailing lists