+44
−33
+0
−3
+0
−13
Loading
maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9GCZS CVE: NA Reference: https://lore.kernel.org/lkml/20240204080144.7977-4-xueshuai@linux.alibaba.com/ -------------------------------- Hardware errors could be signaled by asynchronous interrupt, e.g. when an error is detected by a background scrubber, or signaled by synchronous exception, e.g. when a CPU tries to access a poisoned cache line. Since commit a70297d22132 ("ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events")', the flag MF_ACTION_REQUIRED could be used to determine whether a synchronous exception occurs on ARM64 platform. When a synchronous exception is detected, the kernel should terminate the current process which accessing the poisoned page. This is done by sending a SIGBUS signal with an error code BUS_MCEERR_AR, indicating an action-required machine check error on read. However, the memory failure recovery is incorrectly sending a SIGBUS with wrong error code BUS_MCEERR_AO for synchronous errors in early kill mode, even MF_ACTION_REQUIRED is set. The main problem is that synchronous errors are queued as a memory_failure() work, and are executed within a kernel thread context, not the user-space process that encountered the corrupted memory on ARM64 platform. As a result, when kill_proc() is called to terminate the process, it sends the incorrect SIGBUS error code because the context in which it operates is not the one where the error was triggered. To this end, queue memory_failure() as a task_work so that it runs in the context of the process that is actually consuming the poisoned data, and it will send SIBBUS with si_code BUS_MCEERR_AR. Signed-off-by:Shuai Xue <xueshuai@linux.alibaba.com> Tested-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
Xiaofei Tan <tanxiaofei@huawei.com> Reviewed-by:
Baolin Wang <baolin.wang@linux.alibaba.com> conflicts: drivers/acpi/apei/ghes.c Signed-off-by:
Tong Tiangen <tongtiangen@huawei.com>