Re: [PATCH 0/3][RFC] x86: Catch stray non-kprobe breakpoints

[Ananth N Mavinakayanahalli]

On Tue, Jan 29, 2008 at 02:29:41PM -0500, Masami Hiramatsu wrote:
> Abhishek Sagar wrote:
> > On 1/29/08, Masami Hiramatsu <mhiramat@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/