reentrant probes
Frank Ch. Eigler
fche@redhat.com
Thu Apr 28 20:36:00 GMT 2005
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
More information about the Systemtap
mailing list