reentrant probes

[Seth, Rohit]

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.
 
> 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).

-rohit