Re: reentrant probes

[Prasanna S Panchamukhi <prasanna at in dot ibm dot com>]

Hi,

>>>
>>>Here are some kprobe reentrancy scenarios that may be problematic for
>>>cunning users of systemtap.
>>>
>>>Reentrancy:
>>>   one.stp: probe kernel.function("sys_read") {
>>>   relayfs_printsomething ("yo") } two.stp: probe
>>>   kernel.function("*@relayfs.c") { .... } # Two systemtap sessions
>>>   running concurrently.  Executing the the first # handle causes the
>>>   other handler to be hit.  Reentrancy! 
>>>   # => We want to momentarily block the reentrant relayfs probe hit, 
>>>   but #    flag in two.stp's runtime that this has happened. 
>>>   # We prefer not to disarm  two.stp permanently. 
>>>
>> 
>> 
>> I think it will be quite useful to allow renentrancy in probes.  Not
>> sure why would you want to restrict this.

Reentrancy can be provided, by just disarming the probes temperoraly and
rearming it after the pre/post handler are done. 
This involves following steps.

Detecting that another probe is being hit while handling a current probe.
Disarm the new probe by writting the original instruction back within the 
interrupt handler.
Remove the kprobe from the kprobes list and add it to disarm list.

Queue the work thread to the workqueue for rearming the probe.
Since flushing the instruction cache within the interrupt handler is not 
safe, we queue the work to be handled outside the interrupt context. The worker 
thread just rearms it by writting int3. Also removes the kprobe from the 
disarm list and adds it to the kprobes list.

But there will a small window between the probe being disarmed and
rearmed, were the disarmed probes will be missed.

I will post the patch soon.
Your suggestions are welcome.

Thanks
Prasanna
-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>