reentrant probes

["Frank Ch. Eigler" <fche at redhat 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.

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.

- FChE