lkml.org 
[lkml]   [2015]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Dealing with the NMI mess
    On Thu, 23 Jul 2015 13:21:16 -0700
    Andy Lutomirski <luto@amacapital.net> wrote:

    > 3. Forbid faults (other than MCE) inside NMI.
    >
    > Option 3 is almost easy. There are really only two kinds of faults
    > that can legitimately nest inside NMI: #PF and #DB. #DB is easy to
    > fix (e.g. with my patches or Peter's patches).

    What about int3? Which is needed to make ftrace work. This was a
    requirement to get rid of stomp-machine when updating ftrace functions,
    as well as the rational for doing the whole NMI nesting work in the
    first place.

    >
    > What if we went all out and forbade page faults in NMI as well. There
    > are two reasons that I can think of that we might page fault inside an
    > NMI:
    >
    > a) vmalloc fault. I think Ingo already half-implemented a rework to
    > eliminate vmalloc faults entirely.
    >
    > b) User memory access faults.

    c) stack tracing faults

    I would have NMIs debug deadlocks with printing stack traces. The stack
    tracer can page fault, and before the NMI nesting code, while debugging
    machines, these stack dumps would randomly reboot the box. While
    writing the NMI nesting code I realized why those reboots happened, and
    that was due to the stack trace faulting, and the printk from NMI was
    slow enough to have another NMI go off and stomp over the outer NMIs
    stack. Which lead to triple faults and such.

    -- Steve


    \
     
     \ /
      Last update: 2015-07-23 23:41    [W:4.104 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site