lkml.org 
[lkml]   [2023]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RESEND PATCH v8 2/2] ACPI: APEI: handle synchronous exceptions in task work
    From


    On 2023/9/25 23:00, Jarkko Sakkinen wrote:
    > On Tue Sep 19, 2023 at 5:21 AM EEST, Shuai Xue wrote:
    >> Hardware errors could be signaled by synchronous interrupt, e.g. when an
    >> error is detected by a background scrubber, or signaled by synchronous
    >> exception, e.g. when an uncorrected error is consumed. Both synchronous and
    >> asynchronous error are queued and handled by a dedicated kthread in
    >> workqueue.
    >>
    >> commit 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for
    >> synchronous errors") keep track of whether memory_failure() work was
    >> queued, and make task_work pending to flush out the workqueue so that the
    >> work for synchronous error is processed before returning to user-space.
    >> The trick ensures that the corrupted page is unmapped and poisoned. And
    >> after returning to user-space, the task starts at current instruction which
    >> triggering a page fault in which kernel will send SIGBUS to current process
    >> due to VM_FAULT_HWPOISON.
    >>
    >> However, the memory failure recovery for hwpoison-aware mechanisms does not
    >> work as expected. For example, hwpoison-aware user-space processes like
    >> QEMU register their customized SIGBUS handler and enable early kill mode by
    >> seting PF_MCE_EARLY at initialization. Then the kernel will directy notify
    >> the process by sending a SIGBUS signal in memory failure with wrong
    >> si_code: the actual user-space process accessing the corrupt memory
    >> location, but its memory failure work is handled in a kthread context, so
    >> it will send SIGBUS with BUS_MCEERR_AO si_code to the actual user-space
    >> process instead of BUS_MCEERR_AR in kill_proc().
    >>
    >> To this end, separate synchronous and asynchronous error handling into
    >> different paths like X86 platform does:
    >>
    >> - valid synchronous errors: queue a task_work to synchronously send SIGBUS
    >> before ret_to_user.
    >> - valid asynchronous errors: queue a work into workqueue to asynchronously
    >> handle memory failure.
    >> - abnormal branches such as invalid PA, unexpected severity, no memory
    >> failure config support, invalid GUID section, OOM, etc.
    >>
    >> Then for valid synchronous errors, the current context in memory failure is
    >> exactly belongs to the task consuming poison data and it will send SIBBUS
    >> with proper si_code.
    >>
    >> Fixes: 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors")
    >> 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>
    >
    > Did 7f17b4a121d0 actually break something that was not broken before?
    >
    > If not, this is (afaik) not a bug fix.

    Hi, Jarkko,

    It did not. It keeps track of whether memory_failure() work was queued,
    and makes task_work pending to flush out the queue. But if no work queued for
    synchronous error due to abnormal branches, it does not do a force kill to
    current process resulting a hard lockup due to exception loop.

    It is fine to me to remove the bug fix tag if you insist on removing it.

    Best Regards,
    Shuai

    \
     
     \ /
      Last update: 2023-09-26 08:39    [W:4.046 / U:1.568 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site