| Message ID | 20241104015430.98599-2-xueshuai@linux.alibaba.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v16,1/3] ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered | expand |
On Mon, Nov 04, 2024 at 09:54:28AM +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@linux.alibaba.com> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.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..af3339dd3817 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(HW_ERR GHES_PFX "%s:%d: hardware memory corruption (SIGBUS)\n", Is this always a memory error? The code flow above implies that an unrecoverable ARM processor error can all be !queued. So should the message be more generic like "synchronous unrecoverable error" or similar? In any case, this is just a minor nit if this is not an issue in practice. Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> Thanks, Yazen
On Tue Nov 5, 2024 at 5:09 PM EET, Yazen Ghannam wrote: > > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > > index ada93cfde9ba..af3339dd3817 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(HW_ERR GHES_PFX "%s:%d: hardware memory corruption (SIGBUS)\n", > > Is this always a memory error? The code flow above implies that an > unrecoverable ARM processor error can all be !queued. So should the > message be more generic like "synchronous unrecoverable error" or > similar? > > In any case, this is just a minor nit if this is not an issue in > practice. One minor thing that came to mind after reading your response: wouldn't it be a better idea to use dev_err() against ghes->dev, rather than raw pr_err()? That would better context information and also I just (re-)checked the file and also ghes_remove() is using dev_err(). > > Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> > > Thanks, > Yazen BR, Jarkko
在 2024/11/5 23:09, Yazen Ghannam 写道: > On Mon, Nov 04, 2024 at 09:54:28AM +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@linux.alibaba.com> >> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> >> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.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..af3339dd3817 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(HW_ERR GHES_PFX "%s:%d: hardware memory corruption (SIGBUS)\n", > > Is this always a memory error? The code flow above implies that an > unrecoverable ARM processor error can all be !queued. So should the > message be more generic like "synchronous unrecoverable error" or > similar? Yes, you are right. Will fix it. > > In any case, this is just a minor nit if this is not an issue in > practice. > > Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> > > Thanks, > Yazen Thank you for valuable comments. Shuai
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index ada93cfde9ba..af3339dd3817 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(HW_ERR GHES_PFX "%s:%d: hardware memory corruption (SIGBUS)\n", + current->comm, task_pid_nr(current)); + force_sig(SIGBUS); + } + return queued; }