[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023121847-resistant-fleshy-0c4b@gregkh>
Date: Mon, 18 Dec 2023 07:53:53 +0100
From: Greg KH <gregkh@...uxfoundation.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,
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 02:45:18PM +0800, Shuai Xue 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>
> ---
> drivers/acpi/apei/ghes.c | 29 +++++++++++++++++++++++------
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
Powered by blists - more mailing lists