[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241029204848.GA1229628@yaz-khff2.amd.com>
Date: Tue, 29 Oct 2024 16:48:48 -0400
From: Yazen Ghannam <yazen.ghannam@....com>
To: Shuai Xue <xueshuai@...ux.alibaba.com>
Cc: mark.rutland@....com, catalin.marinas@....com, mingo@...hat.com,
robin.murphy@....com, Jonathan.Cameron@...wei.com, 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,
tongtiangen@...wei.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, x86@...nel.org, justin.he@....com,
ardb@...nel.org, ying.huang@...el.com, ashish.kalra@....com,
baolin.wang@...ux.alibaba.com, tglx@...utronix.de,
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 v15 1/3] ACPI: APEI: send SIGBUS to current task if
synchronous memory error not recovered
On Mon, Oct 28, 2024 at 04:11:40PM +0800, Shuai Xue wrote:
> Synchronous error was detected as a result of user-space process accessing
> a 2-bit uncorrected error. The CPU will take a synchronous error exception
> such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a
> memory_failure() work which poisons the related page, unmaps the page, and
> then sends a SIGBUS to the process, so that a system wide panic can be
> avoided.
>
> However, no memory_failure() work will be queued when abnormal synchronous
> errors occur. These errors can include situations such as invalid PA,
> unexpected severity, no memory failure config support, invalid GUID
> section, etc. In such case, the user-space process will trigger SEA again.
> This loop can potentially exceed the platform firmware threshold or even
> trigger a kernel hard lockup, leading to a system reboot.
>
> Fix it by performing a force kill if no memory_failure() work is queued
> for synchronous errors.
>
> Signed-off-by: Shuai Xue <xueshuai@...ux.alibaba.com>
> Reviewed-by: Jarkko Sakkinen <jarkko@...nel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> ---
> drivers/acpi/apei/ghes.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index ada93cfde9ba..f2ee28c44d7a 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -801,6 +801,16 @@ static bool ghes_do_proc(struct ghes *ghes,
> }
> }
>
> + /*
> + * If no memory failure work is queued for abnormal synchronous
> + * errors, do a force kill.
> + */
> + if (sync && !queued) {
> + pr_err("%s:%d: hardware memory corruption (SIGBUS)\n",
> + current->comm, task_pid_nr(current));
I think it would help to include the GHES_PFX to indicate where this
message is coming from. The pr_fmt() macro could also be introduced
instead.
Also, you may want to include the HW_ERR prefix. Not all kernel messages
related to hardware errors have this prefix today. But maybe that should
be changed so there is more consistent messaging.
Thanks,
Yazen
Powered by blists - more mailing lists