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

[Ananth N Mavinakayanahalli]

Frank Ch. Eigler wrote:
> On Wed, Apr 06, 2005 at 02:11:39PM -0400, Ananth N Mavinakayanahalli wrote:
> 
>>[...]
>>
>>>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?

But how can we deem it is safe to do so? Needs more thought...

>>[...]
>>
>>>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?

Yes, that is the idea, and as Richard mentions, the fault handler could
disarm the probe and pretend no probe had been installed and let the 
kernel handle the rest.

Thanks,
Ananth