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);
+ }
+
return queued;
}
--
2.39.3On 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?
Thanks
Hanjun
在 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().
>
> Thanks
> Hanjun
Thanks.
Shuai
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.
Thanks
Hanjun
在 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
On 2025/4/18 20:35, Shuai Xue wrote:
>
>
> 在 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 :)
Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite,
but I can bear that, please add
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Thanks
Hanjun
在 2025/4/25 09:00, Hanjun Guo 写道:
> On 2025/4/18 20:35, Shuai Xue wrote:
>>
>>
>> 在 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 :)
>
> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite,
> but I can bear that, please add
>
> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
>
> Thanks
> Hanjun
Thanks. Hanjun.
@Rafael, @Catalin,
Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI maintainers, Hanjun,
now. Are you happpy to pick and queue this patch set to acpi tree or arm tree?
If you need me to send a new version to collect the reviewed-by tag, please
let me know.
Thanks.
Best Regards,
Shuai
On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: > 在 2025/4/25 09:00, Hanjun Guo 写道: > > Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, > > but I can bear that, please add > > > > Reviewed-by: Hanjun Guo <guohanjun@huawei.com> > > > > Thanks > > Hanjun > > Thanks. Hanjun. > > @Rafael, @Catalin, > > Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI maintainers, Hanjun, > now. Are you happpy to pick and queue this patch set to acpi tree or arm tree? Since this primarily touches drivers/acpi/apei/ghes.c, I think it should go via the ACPI tree and not the arm64 one. Will
>在 2025/4/28 23:23, Will Deacon 写道: >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: >>> 在 2025/4/25 09:00, Hanjun Guo 写道: >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, >>>> but I can bear that, please add >>>> >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> >>>> >>>> Thanks >>>> Hanjun >>> >>> Thanks. Hanjun. >>> >>> @Rafael, @Catalin, >>> >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI maintainers, Hanjun, >>> now. Are you happpy to pick and queue this patch set to acpi tree or arm tree? >> >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should >> go via the ACPI tree and not the arm64 one. >> >> Will > >Hi, Will, > >Thank you for your confirmation :) > >@Rafael, do you have more comments on this patch set? > >Thanks you. > >Best Regards, >Shuai Hi, all, Gentle ping. Does ACPI or APEI tree still active? Looking forward to any response. Thanks. Best Regards, Shuai
On Tue, Jul 1, 2025 at 1:00 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > > >在 2025/4/28 23:23, Will Deacon 写道: > >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: > >>> 在 2025/4/25 09:00, Hanjun Guo 写道: > >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, > >>>> but I can bear that, please add > >>>> > >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> > >>>> > >>>> Thanks > >>>> Hanjun > >>> > >>> Thanks. Hanjun. > >>> > >>> @Rafael, @Catalin, > >>> > >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI > maintainers, Hanjun, > >>> now. Are you happpy to pick and queue this patch set to acpi tree > or arm tree? > >> > >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should > >> go via the ACPI tree and not the arm64 one. > >> > >> Will > > > >Hi, Will, > > > >Thank you for your confirmation :) > > > >@Rafael, do you have more comments on this patch set? > > > >Thanks you. > > > >Best Regards, > >Shuai > > Hi, all, > > Gentle ping. > > Does ACPI or APEI tree still active? Looking forward to any response. For APEI changes, you need an ACK from one of the reviewers listed in the MAINTAINERS entry for APEI. Thanks!
在 2025/7/1 21:56, Rafael J. Wysocki 写道: > On Tue, Jul 1, 2025 at 1:00 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: >> >> >在 2025/4/28 23:23, Will Deacon 写道: >> >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: >> >>> 在 2025/4/25 09:00, Hanjun Guo 写道: >> >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, >> >>>> but I can bear that, please add >> >>>> >> >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> >> >>>> >> >>>> Thanks >> >>>> Hanjun >> >>> >> >>> Thanks. Hanjun. >> >>> >> >>> @Rafael, @Catalin, >> >>> >> >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI >> maintainers, Hanjun, >> >>> now. Are you happpy to pick and queue this patch set to acpi tree >> or arm tree? >> >> >> >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should >> >> go via the ACPI tree and not the arm64 one. >> >> >> >> Will >> > >> >Hi, Will, >> > >> >Thank you for your confirmation :) >> > >> >@Rafael, do you have more comments on this patch set? >> > >> >Thanks you. >> > >> >Best Regards, >> >Shuai >> >> Hi, all, >> >> Gentle ping. >> >> Does ACPI or APEI tree still active? Looking forward to any response. > > For APEI changes, you need an ACK from one of the reviewers listed in > the MAINTAINERS entry for APEI. > > Thanks! Hi, Rafael Sorry, I missed your email which goes in span (: ARM maintain @Catalin points that: > James Morse is listed as reviewer of the ACPI APEI code but he's busy > with resctrl/MPAM. Adding Lorenzo, Sudeep and Hanjun as arm64 ACPI > maintainers, hopefully they can help. And Hanjun explictly gived his Reviewed-by tag in this thread, is that happy for you for merge? Thanks. Shuai
Hi, On Mon, Jul 14, 2025 at 1:54 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > > 在 2025/7/1 21:56, Rafael J. Wysocki 写道: > > On Tue, Jul 1, 2025 at 1:00 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > >> > >> >在 2025/4/28 23:23, Will Deacon 写道: > >> >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: > >> >>> 在 2025/4/25 09:00, Hanjun Guo 写道: > >> >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, > >> >>>> but I can bear that, please add > >> >>>> > >> >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> > >> >>>> > >> >>>> Thanks > >> >>>> Hanjun > >> >>> > >> >>> Thanks. Hanjun. > >> >>> > >> >>> @Rafael, @Catalin, > >> >>> > >> >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI > >> maintainers, Hanjun, > >> >>> now. Are you happpy to pick and queue this patch set to acpi tree > >> or arm tree? > >> >> > >> >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should > >> >> go via the ACPI tree and not the arm64 one. > >> >> > >> >> Will > >> > > >> >Hi, Will, > >> > > >> >Thank you for your confirmation :) > >> > > >> >@Rafael, do you have more comments on this patch set? > >> > > >> >Thanks you. > >> > > >> >Best Regards, > >> >Shuai > >> > >> Hi, all, > >> > >> Gentle ping. > >> > >> Does ACPI or APEI tree still active? Looking forward to any response. > > > > For APEI changes, you need an ACK from one of the reviewers listed in > > the MAINTAINERS entry for APEI. > > > > Thanks! > > Hi, Rafael > > Sorry, I missed your email which goes in span (: > > ARM maintain @Catalin points that: > > > James Morse is listed as reviewer of the ACPI APEI code but he's busy > > with resctrl/MPAM. Adding Lorenzo, Sudeep and Hanjun as arm64 ACPI > > maintainers, hopefully they can help. > > And Hanjun explictly gived his Reviewed-by tag in this thread, is that > happy for you for merge? Not really. I need an ACK or R-by from a reviewer listed in the APEI entry in MAINTAINERS. If James Morse is not able to fill that role (and AFAICS he's not been for quite some time now), I'd expect someone else to step up. Thanks!
Em Mon, 14 Jul 2025 19:30:19 +0200 "Rafael J. Wysocki" <rafael@kernel.org> escreveu: > Hi, > > On Mon, Jul 14, 2025 at 1:54 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > > > > 在 2025/7/1 21:56, Rafael J. Wysocki 写道: > > > On Tue, Jul 1, 2025 at 1:00 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > > >> > > >> >在 2025/4/28 23:23, Will Deacon 写道: > > >> >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: > > >> >>> 在 2025/4/25 09:00, Hanjun Guo 写道: > > >> >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, > > >> >>>> but I can bear that, please add > > >> >>>> > > >> >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> > > >> >>>> > > >> >>>> Thanks > > >> >>>> Hanjun > > >> >>> > > >> >>> Thanks. Hanjun. > > >> >>> > > >> >>> @Rafael, @Catalin, > > >> >>> > > >> >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI > > >> maintainers, Hanjun, > > >> >>> now. Are you happpy to pick and queue this patch set to acpi tree > > >> or arm tree? > > >> >> > > >> >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should > > >> >> go via the ACPI tree and not the arm64 one. > > >> >> > > >> >> Will > > >> > > > >> >Hi, Will, > > >> > > > >> >Thank you for your confirmation :) > > >> > > > >> >@Rafael, do you have more comments on this patch set? > > >> > > > >> >Thanks you. > > >> > > > >> >Best Regards, > > >> >Shuai > > >> > > >> Hi, all, > > >> > > >> Gentle ping. > > >> > > >> Does ACPI or APEI tree still active? Looking forward to any response. > > > > > > For APEI changes, you need an ACK from one of the reviewers listed in > > > the MAINTAINERS entry for APEI. > > > > > > Thanks! > > > > Hi, Rafael > > > > Sorry, I missed your email which goes in span (: > > > > ARM maintain @Catalin points that: > > > > > James Morse is listed as reviewer of the ACPI APEI code but he's busy > > > with resctrl/MPAM. Adding Lorenzo, Sudeep and Hanjun as arm64 ACPI > > > maintainers, hopefully they can help. > > > > And Hanjun explictly gived his Reviewed-by tag in this thread, is that > > happy for you for merge? > > Not really. > > I need an ACK or R-by from a reviewer listed in the APEI entry in MAINTAINERS. > > If James Morse is not able to fill that role (and AFAICS he's not been > for quite some time now), I'd expect someone else to step up. Rafael, If you want, I can step-up to help with APEI review. Besides my work with RAS/EDAC in the past, I'm doing some work those days adding APEI injection in QEMU those days (currently focused on ARM error injection via SEA and GPIO). Regards, Mauro
On Tue, Jul 15, 2025 at 2:06 PM Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote: > > Em Mon, 14 Jul 2025 19:30:19 +0200 > "Rafael J. Wysocki" <rafael@kernel.org> escreveu: > > > Hi, > > > > On Mon, Jul 14, 2025 at 1:54 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > > > > > > 在 2025/7/1 21:56, Rafael J. Wysocki 写道: > > > > On Tue, Jul 1, 2025 at 1:00 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: > > > >> > > > >> >在 2025/4/28 23:23, Will Deacon 写道: > > > >> >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: > > > >> >>> 在 2025/4/25 09:00, Hanjun Guo 写道: > > > >> >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, > > > >> >>>> but I can bear that, please add > > > >> >>>> > > > >> >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> > > > >> >>>> > > > >> >>>> Thanks > > > >> >>>> Hanjun > > > >> >>> > > > >> >>> Thanks. Hanjun. > > > >> >>> > > > >> >>> @Rafael, @Catalin, > > > >> >>> > > > >> >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI > > > >> maintainers, Hanjun, > > > >> >>> now. Are you happpy to pick and queue this patch set to acpi tree > > > >> or arm tree? > > > >> >> > > > >> >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should > > > >> >> go via the ACPI tree and not the arm64 one. > > > >> >> > > > >> >> Will > > > >> > > > > >> >Hi, Will, > > > >> > > > > >> >Thank you for your confirmation :) > > > >> > > > > >> >@Rafael, do you have more comments on this patch set? > > > >> > > > > >> >Thanks you. > > > >> > > > > >> >Best Regards, > > > >> >Shuai > > > >> > > > >> Hi, all, > > > >> > > > >> Gentle ping. > > > >> > > > >> Does ACPI or APEI tree still active? Looking forward to any response. > > > > > > > > For APEI changes, you need an ACK from one of the reviewers listed in > > > > the MAINTAINERS entry for APEI. > > > > > > > > Thanks! > > > > > > Hi, Rafael > > > > > > Sorry, I missed your email which goes in span (: > > > > > > ARM maintain @Catalin points that: > > > > > > > James Morse is listed as reviewer of the ACPI APEI code but he's busy > > > > with resctrl/MPAM. Adding Lorenzo, Sudeep and Hanjun as arm64 ACPI > > > > maintainers, hopefully they can help. > > > > > > And Hanjun explictly gived his Reviewed-by tag in this thread, is that > > > happy for you for merge? > > > > Not really. > > > > I need an ACK or R-by from a reviewer listed in the APEI entry in MAINTAINERS. > > > > If James Morse is not able to fill that role (and AFAICS he's not been > > for quite some time now), I'd expect someone else to step up. Hi Mauro, > Rafael, > > If you want, I can step-up to help with APEI review. Besides my work > with RAS/EDAC in the past, I'm doing some work those days adding > APEI injection in QEMU those days (currently focused on ARM error > injection via SEA and GPIO). Thank you! OK, let me send a MAINTAINERS update with a list of new APEI reviewers.
On 2025/7/15 1:30, Rafael J. Wysocki wrote: >>> For APEI changes, you need an ACK from one of the reviewers listed in >>> the MAINTAINERS entry for APEI. >>> >>> Thanks! >> Hi, Rafael >> >> Sorry, I missed your email which goes in span (: >> >> ARM maintain @Catalin points that: >> >> > James Morse is listed as reviewer of the ACPI APEI code but he's busy >> > with resctrl/MPAM. Adding Lorenzo, Sudeep and Hanjun as arm64 ACPI >> > maintainers, hopefully they can help. >> >> And Hanjun explictly gived his Reviewed-by tag in this thread, is that >> happy for you for merge? > Not really. > > I need an ACK or R-by from a reviewer listed in the APEI entry in MAINTAINERS. > > If James Morse is not able to fill that role (and AFAICS he's not been > for quite some time now), I'd expect someone else to step up. Please count me in. I have been working in ACPI for years, and RAS feature development for both x86 and arm64 architectures. I'm pretty familiar with ACPI spec including APEI, it will help me to do the review work. Thanks Hanjun
在 2025/7/15 01:30, Rafael J. Wysocki 写道: > Hi, > > On Mon, Jul 14, 2025 at 1:54 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: >> >> 在 2025/7/1 21:56, Rafael J. Wysocki 写道: >>> On Tue, Jul 1, 2025 at 1:00 PM Shuai Xue <xueshuai@linux.alibaba.com> wrote: >>>> >>>> >在 2025/4/28 23:23, Will Deacon 写道: >>>> >> On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: >>>> >>> 在 2025/4/25 09:00, Hanjun Guo 写道: >>>> >>>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, >>>> >>>> but I can bear that, please add >>>> >>>> >>>> >>>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> >>>> >>>> >>>> >>>> Thanks >>>> >>>> Hanjun >>>> >>> >>>> >>> Thanks. Hanjun. >>>> >>> >>>> >>> @Rafael, @Catalin, >>>> >>> >>>> >>> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI >>>> maintainers, Hanjun, >>>> >>> now. Are you happpy to pick and queue this patch set to acpi tree >>>> or arm tree? >>>> >> >>>> >> Since this primarily touches drivers/acpi/apei/ghes.c, I think it should >>>> >> go via the ACPI tree and not the arm64 one. >>>> >> >>>> >> Will >>>> > >>>> >Hi, Will, >>>> > >>>> >Thank you for your confirmation :) >>>> > >>>> >@Rafael, do you have more comments on this patch set? >>>> > >>>> >Thanks you. >>>> > >>>> >Best Regards, >>>> >Shuai >>>> >>>> Hi, all, >>>> >>>> Gentle ping. >>>> >>>> Does ACPI or APEI tree still active? Looking forward to any response. >>> >>> For APEI changes, you need an ACK from one of the reviewers listed in >>> the MAINTAINERS entry for APEI. >>> >>> Thanks! >> >> Hi, Rafael >> >> Sorry, I missed your email which goes in span (: >> >> ARM maintain @Catalin points that: >> >> > James Morse is listed as reviewer of the ACPI APEI code but he's busy >> > with resctrl/MPAM. Adding Lorenzo, Sudeep and Hanjun as arm64 ACPI >> > maintainers, hopefully they can help. >> >> And Hanjun explictly gived his Reviewed-by tag in this thread, is that >> happy for you for merge? > > Not really. > > I need an ACK or R-by from a reviewer listed in the APEI entry in MAINTAINERS. Hi Rafael, I understand your requirement for an ACK/R-by from the APEI reviewers listed in MAINTAINERS. So, @Tony, @James, @Borislav, @Len, Gentle ping, we need your help to review and ack this patch set. If I recall correctly, Rafael has mentioned this issue at least three times in previous emails, but we still haven't received explict response from the APEI maintainer. > > If James Morse is not able to fill that role (and AFAICS he's not been > for quite some time now), I'd expect someone else to step up. > > Thanks! Thank you for the clarification. I'd like to volunteer to help with APEI code reviews. I have been working with APEI-related code and am familiar with the ACPI error handling mechanisms. I'm willing to start by contributing reviews and help move pending APEI patches forward. If the community finds my contributions valuable and believes I have the necessary expertise, I would welcome the opportunity to be formally set up as an APEI reviewer in the future. Thanks for considering this, and I look forward to your guidance. Thanks. Shuai
在 2025/4/28 23:23, Will Deacon 写道: > On Fri, Apr 25, 2025 at 09:10:09AM +0800, Shuai Xue wrote: >> 在 2025/4/25 09:00, Hanjun Guo 写道: >>> Call force_sig(SIGBUS) directly in ghes_do_proc() is not my favourite, >>> but I can bear that, please add >>> >>> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> >>> >>> Thanks >>> Hanjun >> >> Thanks. Hanjun. >> >> @Rafael, @Catalin, >> >> Both patch 1 and 2 have reviewed-by tag from the arm64 ACPI maintainers, Hanjun, >> now. Are you happpy to pick and queue this patch set to acpi tree or arm tree? > > Since this primarily touches drivers/acpi/apei/ghes.c, I think it should > go via the ACPI tree and not the arm64 one. > > Will Hi, Will, Thank you for your confirmation :) @Rafael, do you have more comments on this patch set? Thanks you. Best Regards, Shuai
© 2016 - 2025 Red Hat, Inc.