Re: [RFC] Design + prototype: Multiple kprobes at an address - take 2

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Wed, Apr 06, 2005 at 02:11:39PM -0400, Ananth N Mavinakayanahalli wrote:
> [...]
> >One possibility is to add the [flag] to the kprobe struct, and set it
> >within disarm_kprobe.  [...]  The clients could get the flag in
> >their own kprobe struct updated during the kprobe_unregister() call.
> 
> Or even better, check for the flag when you return to aggr_pre_handler
> and set it in each of the kprobes in the list.

Sure.  Doing the check/copy there would be a slight performance hit in
a hot path, but on the other hand would let a kprobes client find out
earlier about the problem. 


> [...]
> >By the way, why is complete disarming (removal) deemed the appropriate
> >response to reentrant probes?  What would go wrong if a nested kprobe
> >call would be only ignored somehow, and go right to the
> >single-stepping of its target instruction?  [...]
> 
> How/when will you reset the re-entry flag to revoke suspension and
> start processing the probes as normal? How/when do you know it is safe
> to do so?

Perhaps when the outer kprobe pre/post handler has returned?


> [...]
> >What can a custom kprobes fault handler do if a user-level instruction
> >causes a fault?  [...]
> 
> If you look at the notifier hooks that invoke the fault handler, they
> are only at the entry of the page_fault and general protection paths,
> and are used to shield the kernel from seeing this fault if caused by
> the probes. [...]

Yes, "caused by the probes" i.e., providing protection to buggy
pre/post handlers.  What I don't understand (and rereading Richard's
message didn't help) is how *single-stepping the user code* could
trigger a fault, and do so in such a way that the kprobes-registered
handler could do something useful with it.

Is the idea that the single-stepped user instruction would e.g.,
perform memory access to an address that happens to be paged out, to
cause an ordinary page fault?  OK, so you don't want the kernel to
process that as a page fault right there because of the int3 context
(right?).  I can imagine this happening, but what could a user-defined
kprobes handler do to the user program to let it recover?


- FChE

Attachment: pgp00000.pgp
Description: PGP signature