Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1191835

Re: Dealing with the NMI mess

From Willy Tarreau <w@1wt.eu>
Newsgroups linux.kernel
Subject Re: Dealing with the NMI mess
Date 2015-07-24 15:30 +0200
Message-ID <pPLd1-71j-23@gated-at.bofh.it> (permalink)
References (5 earlier) <pPwQG-30s-17@gated-at.bofh.it> <pPGmZ-8tY-7@gated-at.bofh.it> <pPJNW-4T4-35@gated-at.bofh.it> <pPKAh-62N-15@gated-at.bofh.it> <pPKTE-6EB-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Jul 24, 2015 at 09:03:42AM -0400, Steven Rostedt wrote:
> On Fri, 24 Jul 2015 14:43:04 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
>  
> > > I'm not too familiar with how to use hw breakpoints, but I'm guessing
> > > (correct me if I'm wrong) that breakpoints on code that trigger when
> > > executed, but watchpoints on data trigger when accessed. Then
> > > copy_from_user_inatomic() would only trigger on watchpoints (it's not
> > > executing that code, at least I hope it isn't!), and those wont bother
> > > us.
> > 
> > These things can be: RW, W, X.
> > 
> > Sure, hitting a user X watchpoint is going to be 'interesting', but its
> > fairly easy to hit a RW one.
> 
> But do we care if we do hit one? The return from the #DB handler can
> use a RET. Right?

My understanding is that by using RET we can't set the RF flag and #DB
will immediately strike again when the operation is attempted again. Thus
we have to completely disable the breakpoints on leaving after the first
one strikes, resulting in some userland breakpoints being missed. Maybe
it can be accepted as a limitation when perf is running. I don't know if
the output of perf is that relevant when a debugger is present BTW.

Willy

--
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 | NextPrevious in thread | 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