lkml.org 
[lkml]   [2008]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3][RFC] x86: Catch stray non-kprobe breakpoints
On Tue, Jan 29, 2008 at 02:29:41PM -0500, Masami Hiramatsu wrote:
> Abhishek Sagar wrote:
> > On 1/29/08, Masami Hiramatsu <mhiramat@redhat.com> wrote:
> >> In that case, why don't you just reduce the priority of kprobe_exceptions_nb?
> >> Then, the execution path becomes very simple.
> >
> > Ananth mentioned that the kprobe notifier has to be the first to run.
>
> (Hmm.. I think he has just explained current implementation:))
> IMHO, since kprobes itself can not know what the external debugger
> wants to do, the highest priority should be reserved for those external tools.

The reason why kprobes needs to be the first to run is simple: it
doesn't need user intervention and if it isn't the intended recepient of
the breakpoint, it just lets the kernel take over (unlike a debugger,
which would potentially need user attention). Also, if the underlying
instruction itself is a breakpoint, we have the facility in kprobes to
single-step inline so the kernel can take control and notify any other
intended recepient of the underlying breakpoint.

As such, I believe the current situation is fine, has worked fine for
close to 4 years now and doesn't warrant any change.

Ananth


\
 
 \ /
  Last update: 2008-01-30 05:09    [W:0.281 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site