Re: reentrant probes

[Ananth N Mavinakayanahalli <amavin at redhat dot com>]

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