Groups > linux.kernel > #1191334

Re: Dealing with the NMI mess

From	Steven Rostedt <rostedt@goodmis.org>
Newsgroups	linux.kernel
Subject	Re: Dealing with the NMI mess
Date	2015-07-23 23:40 +0200
Message-ID	<pPwnF-2cG-37@gated-at.bofh.it> (permalink)
References	<pPvhU-Eb-7@gated-at.bofh.it> <pPvrA-QP-15@gated-at.bofh.it> <pPvBg-12v-15@gated-at.bofh.it> <pPvUC-1EG-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, 23 Jul 2015 14:08:59 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Jul 23, 2015 at 1:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > Issue A: to return with RF clear, we need to disarm the breakpoint.
> > If it's limited to the duration of the NMI, that's easy.  If not, when
> > do we re-arm?  New prepare_exit_to_usermode hook?  Hmm, setting ti
> > flags during context switch may target the wrong task.
> 
> We don't re-arm it.
> 

Let me get this straight. The idea is in the #DB handler to detect that
it was triggered in NMI context, and if so, simply disarm that
breakpoint permanently, right?

Nothing should be adding hw breakpoints to NMI code anyway. Sounds
perfectly reasonable to me. Of course, how we tell we are in NMI
brings back all the races as we had in the nesting code. We can check
the per-cpu variable that is set with nmi_enter() and cleared at
nmi_exit() but what happens if the breakpoint is outside those calls.
We can check the stack pointer, but then we are back to userspace
fooling us. Maybe add the DF trick again?

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Dealing with the NMI mess Steven Rostedt <rostedt@goodmis.org> - 2015-07-23 23:40 +0200
  Re: Dealing with the NMI mess Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-23 23:50 +0200
    Re: Dealing with the NMI mess Andy Lutomirski <luto@amacapital.net> - 2015-07-24 00:00 +0200
      Re: Dealing with the NMI mess Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-24 00:10 +0200
        Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 10:20 +0200
          Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-24 11:10 +0200
          Re: Dealing with the NMI mess Steven Rostedt <rostedt@goodmis.org> - 2015-07-24 14:00 +0200
            Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 14:50 +0200
              Re: Dealing with the NMI mess Steven Rostedt <rostedt@goodmis.org> - 2015-07-24 15:10 +0200
                Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-24 15:30 +0200
                Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 15:40 +0200
                Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 15:40 +0200
                Re: Dealing with the NMI mess Paolo Bonzini <pbonzini@redhat.com> - 2015-07-30 17:50 +0200
                Re: Dealing with the NMI mess Borislav Petkov <bp@alien8.de> - 2015-07-31 06:30 +0200
          Re: Dealing with the NMI mess Paolo Bonzini <pbonzini@redhat.com> - 2015-07-30 18:00 +0200
  Re: Dealing with the NMI mess Andy Lutomirski <luto@amacapital.net> - 2015-07-23 23:50 +0200
    Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-24 00:00 +0200
  Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-23 23:50 +0200

csiph-web