reentrant probes

[Ananth N Mavinakayanahalli]

Seth, Rohit wrote:
> Frank Ch. Eigler <> wrote on Thursday, April 28, 2005 1:36 PM:
> Hi Frank,
> 
> 
>>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.

I think the question is more about how to determine when is it safe to
rearm the probe - can we figure this out deterministically?

> 
>>Concurrency:
>>   probe kernel.syscall("read") { ... }
>>   # Two processors with user code concurrently calling read(2).
>>   # => We want to execute the probe handlers concurrently, and
>>   #    not lock out the other kprobe hit event, to avoid
>>   #    timing interference.
> 
> 
> Agree with this part that probe handlers should be SMP safe (...as they
> are executing in kernel space/context).
> 

Yes, concurrency imposes that the handlers written be smp-safe. However,
current kprobe users did not have to bother about making their handlers
smp safe 'cos the lower layer serializes kprobe handling. However, I'd
like to see a generic change in the kprobe layer rather than having
special casings for users who can/cannot handle concurrency .

Wondering if it would it be fair to impose a restriction and say:
existing kprobe users should make their handlers smp safe if they are
not already?

Ananth