Bug 10995 - on-the-fly enabled/disabled probes
Summary: on-the-fly enabled/disabled probes
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Jonathan Lebon
URL:
Keywords:
Depends on: 4935 6933
Blocks: 11550 11179
  Show dependency treegraph
 
Reported: 2009-11-20 22:42 UTC by Frank Ch. Eigler
Modified: 2014-08-11 21:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2009-11-20 22:42:16 UTC
Bug #4935 included script syntax to designate probe enabling conditions,
and bug #6933 has implemented some support for lightweight kprobe
dis/rearming, but the translator is not actually emitting any code to
connect the two.

We should extend the translator and the various probe point family
implementations (tapset*cxx) to support disarm/rearm operations.
The translator would then have to emit code for the probe point
conditionals to invoke disarm/rearm based upon transitions of the
predicate expression values.
Comment 1 Jim Keniston 2009-11-21 01:04:56 UTC
On a related note, in the SystemTap-resident versions of uprobes, a u[ret]probe
handler can call [un]register_u[ret]probe().  A handler can even unregister
itself.  See Section 4.4, "User's Callback for Delayed Registrations", in
runtime/uprobes/uprobes.txt.

U[ret]probe handlers can block, so they could also [un]register k[ret]probes.
Comment 2 Frank Ch. Eigler 2012-12-11 20:23:14 UTC
bug #6503 added a derived_probe_group code generation function to emit_module_refresh().  The code this generates would need to be extended with per-probe predicate/registration-status bits in the runtime, and with code to do any sort of lightweight arming/disarming that the probe system permits.  The predicate-status bits would be mutexfully maintained by other code that re-evaluates the probe predicate expressions periodically, or whenever the input globals are suspected to change value.
Comment 3 Jonathan Lebon 2014-06-12 19:27:03 UTC
I've been working on this feature for a while. I've just pushed to the jlebon/onthefly branch preliminary work to support this. Currently supported are hrtimer probes and kprobes.

You can use the -DDEBUG_STP_ON_THE_FLY directive to see it in action during runtime (outputs to dmesg). Here's a sample (with relevant dmesg output interspersed):

$ stap -DDEBUG_STP_ON_THE_FLY -e '
global enabled = 0
probe timer.s(1) if (enabled) {
   println("enabled!")
}
probe timer.s(5) {
   println("toggling enable")
   enabled = !enabled
}'



***** DMESG *****
[ 1490.643619] stap_9ea625b9fc91177d0b2a6490acd27b5_20639: systemtap: 2.6/0.158, base: ffffffffa0295000, memory: 31data/24text/1ctx/2058net/17alloc kb, probes: 2
[ 1490.643625] systemtap_module_init:470 not starting (hrtimer) pidx 0
[ 1490.644421] systemtap_module_init:486 started (hrtimer) pidx 1
*****************



toggling enable



***** DMESG *****
[ 1495.644483] _stp_hrtimer_notify_function:298 scheduling work
[ 1495.645261] module_refresher:68 calling systemtap_module_refresh()
[ 1495.645474] systemtap_module_refresh:538 enabling (hrtimer) pidx 0
*****************



enabled!
enabled!
enabled!
enabled!
toggling enable



***** DMESG *****
[ 1500.644483] _stp_hrtimer_notify_function:298 scheduling work
[ 1500.645275] module_refresher:68 calling systemtap_module_refresh()
[ 1500.646036] systemtap_module_refresh:541 disabling (hrtimer) pidx 0
*****************



toggling enable



***** DMESG *****
[ 1505.644484] _stp_hrtimer_notify_function:298 scheduling work
[ 1505.645287] module_refresher:68 calling systemtap_module_refresh()
[ 1505.646069] systemtap_module_refresh:538 enabling (hrtimer) pidx 0
*****************
Comment 4 Jonathan Lebon 2014-08-11 19:59:04 UTC
The jlebon/onthefly branch has been merged into master (merge commit 2e9f9de). I will open another PR for tracking on-the-fly support for other probe types.
Comment 5 Jonathan Lebon 2014-08-11 21:14:33 UTC
(In reply to Jonathan Lebon from comment #4)
> I will open another PR for tracking on-the-fly support for other
> probe types.

For reference, the other PR is bug #17256.