This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: reentrant probes
- From: "Seth, Rohit" <rohit dot seth at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>, <systemtap at sources dot redhat dot com>
- Date: Mon, 2 May 2005 10:16:17 -0700
- Subject: RE: reentrant probes
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