lkml.org 
[lkml]   [2017]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [question] handle the page table RAS error
    On Sun, Dec 03, 2017 at 01:22:25PM +0000, gengdongjiu wrote:
    > Hi all,
    > Sorry to disturb you. Now the ARM64 has supported the RAS, when enabling this feature, we encounter a issue. If the user space application happen page table RAS error,
    > Memory error handler(memory_failure()) will do nothing except make a poisoned page flag, and fault handler in arch/arm64/mm/fault.c will deliver a signal to kill this
    > application. when this application exit, it will call unmap_vmas () to release his vma resource, but here it will touch the error page table again, then will trigger RAS error again, so
    > this application cannot be killed and system will be panic, the log is shown in [2].
    >
    > As shown the stack in [1], unmap_page_range() will touch the error page table, so system will panic, does this panic behavior is expected? How the x86 handle the page table
    > RAS error? If user space application happen page table RAS error, I think the expected behavior should be killing the application instead of panic OS. In current code, when release
    > application vma resource, I do not see it will check whether table page is poisoned, could you give me some suggestion about how to handle this case? Thanks a lot.

    x86 doesn't handle it.

    There are lots of memory types that are not handled by MCE recovery
    because it is just too difficult. In general MCE recovery focuses on
    memory types that use up significant percent of total memory. Page tables
    are normally not that big, so not really worth handling.

    I wouldn't bother about them unless you measure them to big a significant
    portion of memory on a real world workload.

    -Andi

    \
     
     \ /
      Last update: 2017-12-05 17:57    [W:3.364 / U:0.596 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site