From: Shuai Xue <xueshuai@linux.alibaba.com>
To: Hanjun Guo <guohanjun@huawei.com>,
"Luck, Tony" <tony.luck@intel.com>,
rafael@kernel.org, Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, linux-edac@vger.kernel.org,
x86@kernel.org, justin.he@arm.com, ardb@kernel.org,
ying.huang@linux.alibaba.com, ashish.kalra@amd.com,
baolin.wang@linux.alibaba.com, tglx@linutronix.de,
dave.hansen@linux.intel.com, lenb@kernel.org, hpa@zytor.com,
robert.moore@intel.com, lvying6@huawei.com, xiexiuqi@huawei.com,
zhuo.song@linux.alibaba.com, Hanjun Guo <guohanjun@huawei.com>,
catalin.marinas@arm.com, sudeep.holla@arm.com,
lpieralisi@kernel.org, linux-acpi@vger.kernel.org,
yazen.ghannam@amd.com, mark.rutland@arm.com, mingo@redhat.com,
robin.murphy@arm.com, Jonathan.Cameron@Huawei.com, bp@alien8.de,
rafael@kernel.org, linux-arm-kernel@lists.infradead.org,
wangkefeng.wang@huawei.com, tanxiaofei@huawei.com,
mawupeng1@huawei.com, tony.luck@intel.com, linmiaohe@huawei.com,
naoya.horiguchi@nec.com, james.morse@arm.com,
tongtiangen@huawei.com, gregkh@linuxfoundation.org,
will@kernel.org, jarkko@kernel.org
Subject: Re: [RESEND PATCH v18 1/2] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered
Date: Fri, 18 Apr 2025 20:35:03 +0800 [thread overview]
Message-ID: <653abdd4-46d2-4956-b49c-8f9c309af34d@linux.alibaba.com> (raw)
In-Reply-To: <353809e7-5373-0d54-6ddb-767bc5af9e5f@huawei.com>
在 2025/4/18 15:48, Hanjun Guo 写道:
> On 2025/4/14 23:02, Shuai Xue wrote:
>>
>>
>> 在 2025/4/14 22:37, Hanjun Guo 写道:
>>> On 2025/4/4 19:20, 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@linux.alibaba.com>
>>>> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
>>>> Reviewed-by: Jane Chu <jane.chu@oracle.com>
>>>> ---
>>>> drivers/acpi/apei/ghes.c | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>>>> index b72772494655..50e4d924aa8b 100644
>>>> --- a/drivers/acpi/apei/ghes.c
>>>> +++ b/drivers/acpi/apei/ghes.c
>>>> @@ -799,6 +799,17 @@ 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) {
>>>> + dev_err(ghes->dev,
>>>> + HW_ERR GHES_PFX "%s:%d: synchronous unrecoverable error (SIGBUS)\n",
>>>> + current->comm, task_pid_nr(current));
>>>> + force_sig(SIGBUS);
>>>> + }
>>>
>>> I think it's reasonable to send a force kill to the task when the
>>> synchronous memory error is not recovered.
>>>
>>> But I hope this code will not trigger some legacy firmware issues,
>>> let's be careful for this, so can we just introduce arch specific
>>> callbacks for this?
>>
>> Sorry, can you give more details? I am not sure I got your point.
>>
>> For x86, Tony confirmed that ghes will not dispatch x86 synchronous errors
>> (a.k.a machine check exception), in previous vesion.
>> Sync is only used in arm64 platform, see is_hest_sync_notify().
>
> Sorry for the late reply, from the code I can see that x86 will reuse
> ghes_do_proc(), if Tony confirmed that x86 is OK, it's OK to me as well.
Hi, Hanjun,
Glad to hear that.
I copy and paste in the original disscusion with @Tony from mailist.[1]
> On x86 the "action required" cases are signaled by a synchronous machine check
> that is delivered before the instruction that is attempting to consume the uncorrected
> data retires. I.e., it is guaranteed that the uncorrected error has not been propagated
> because it is not visible in any architectural state.
> APEI signaled errors don't fall into that category on x86 ... the uncorrected data
> could have been consumed and propagated long before the signaling used for
> APEI can alert the OS.
I also add comments in the code.
/*
* 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;
}
If you are happy with code, please explictly give me your reviewed-by tags :)
>
> Thanks
> Hanjun
Thanks.
Best Regards,
Shuai
[1] https://lore.kernel.org/lkml/CAJZ5v0hdgxsDiXqOmeqBQoZUQJ1RssM=3jpYpWt3qzy0n2eyaA@mail.gmail.com/t/#u
next prev parent reply other threads:[~2025-04-18 12:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-04 11:20 [RESEND PATCH v18 0/2] ACPI: APEI: handle synchronous errors in task work Shuai Xue
2025-04-04 11:20 ` [RESEND PATCH v18 1/2] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered Shuai Xue
2025-04-14 14:37 ` Hanjun Guo
2025-04-14 15:02 ` Shuai Xue
2025-04-18 7:48 ` Hanjun Guo
2025-04-18 12:35 ` Shuai Xue [this message]
2025-04-25 1:00 ` Hanjun Guo
2025-04-25 1:10 ` Shuai Xue
2025-04-28 15:23 ` Will Deacon
2025-05-14 1:35 ` Shuai Xue
2025-07-01 11:00 ` Shuai Xue
2025-07-01 13:56 ` Rafael J. Wysocki
2025-07-14 11:54 ` Shuai Xue
2025-07-14 17:30 ` Rafael J. Wysocki
2025-07-15 2:03 ` Shuai Xue
2025-07-15 2:46 ` Hanjun Guo
2025-07-15 12:06 ` Mauro Carvalho Chehab
2025-07-15 12:40 ` Rafael J. Wysocki
2025-04-04 11:20 ` [RESEND PATCH v18 2/2] ACPI: APEI: handle synchronous exceptions in task work Shuai Xue
2025-04-14 14:48 ` Hanjun Guo
2025-04-14 14:56 ` Shuai Xue
2025-04-08 2:34 ` [RESEND PATCH v18 0/2] ACPI: APEI: handle synchronous errors " Hanjun Guo
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=653abdd4-46d2-4956-b49c-8f9c309af34d@linux.alibaba.com \
--to=xueshuai@linux.alibaba.com \
--cc=Jonathan.Cameron@Huawei.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=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=hpa@zytor.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-arm-kernel@lists.infradead.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lpieralisi@kernel.org \
--cc=lvying6@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mawupeng1@huawei.com \
--cc=mingo@redhat.com \
--cc=naoya.horiguchi@nec.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=robin.murphy@arm.com \
--cc=sudeep.holla@arm.com \
--cc=tanxiaofei@huawei.com \
--cc=tglx@linutronix.de \
--cc=tongtiangen@huawei.com \
--cc=tony.luck@intel.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xiexiuqi@huawei.com \
--cc=yazen.ghannam@amd.com \
--cc=ying.huang@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.