lkml.org 
[lkml]   [2011]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [PATCH 5/9] HWPoison: add memory_failure_queue()
    >> - NMI handler run for the hardware error, where hardware error
    >> information is collected and put into perf ring buffer as 'event'.
    >
    > Correct.
    >
    > Note that for MCE errors we want the 'persistent event' framework Boris has
    > posted: we want these events to be buffered up to a point even if there is no
    > tool listening in on them:

    This is a very opportune time to have this discussion. I've been working
    on getting "in context" recoverable errors working. Sandybridge Server
    platforms will allow for recovery for both instruction and data fetches
    in the current execution context. These are flagged in the machine check
    bank with the "AR" (Action Required) set to 1 (along with several other
    bits making up a recognizable signature).

    The critical feature here is that we must not return from the machine
    check handler to the context that tripped over the error. In the case
    of the data fault, we'll just re-execute the same access and take
    another machine check. In the case of the instruction fault there is
    no valid context to return to (MCGSTATUS.RIPV is zero).

    There are a couple of cases where recovery is possible:

    1) The memory error was found while executing user mode code.

    The code I have now for recovery makes use of TIF_MCE_NOTIFY to
    make sure that we don't return to the user, but instead end up
    in arch/x86/kernel/signal.c:do_notify_resume() where we arrange
    to have the process handle its own recovery (using mm/memory-failure.c
    to figure out the type of page, and probably resulting in the mapping
    out of the page and sending SIGBUS to the process).

    In your proposed solution, we'd generate an event that would be handled
    by some process/daemon ... but how would we ensure that the affected
    process does not run in the mean time? Could we create some analogous
    method to the ptrace stopped state, and hand control of the affected
    process to the daemon that gets the event?

    2) The memory error was found in certain special sections of the
    kernel for which recovery is possible (e.g. while copying to/from
    user memory, perhaps also page copy and page clear).

    Here I don't have a solution. TIF_MCE_NOTIFY isn't checked when returning
    from do_machine_check() to kernel code.

    In a CONFIG_PREEMPT=y kernel, all of the recoverable cases ought to be
    in places where pre-emption is allowed ... so perhaps we can also use
    the stop-and-switch option here?

    -Tony



    \
     
     \ /
      Last update: 2011-05-23 18:49    [W:0.029 / U:122.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site