Bug 4935 - support on-the-fly probe enable/disable syntax
Summary: support on-the-fly probe enable/disable syntax
Status: RESOLVED DUPLICATE of bug 6933
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Frank Ch. Eigler
URL:
Keywords:
Depends on: 6933
Blocks: 3859 10995
  Show dependency treegraph
 
Reported: 2007-08-17 18:35 UTC by Frank Ch. Eigler
Modified: 2009-05-20 15:51 UTC (History)
2 users (show)

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


Attachments
on-the-fly enable/disable probes patch for parser and elabolator (2.38 KB, patch)
2007-11-16 23:40 UTC, Masami Hiramatsu
Details | Diff
A bugfix patch for on-the-fly probe enable/disable syntax (528 bytes, patch)
2007-11-27 16:02 UTC, Masami Hiramatsu
Details | Diff
Documentation patch for on-the-fly probe enable/disable syntax (948 bytes, patch)
2007-12-04 20:45 UTC, Masami Hiramatsu
Details | Diff
Testcases for on-the-fly probe enable/disable syntax (1.29 KB, patch)
2007-12-04 20:47 UTC, Masami Hiramatsu
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2007-08-17 18:35:37 UTC
See http://sourceware.org/ml/systemtap/2007-q3/msg00023.html for
one possibility.
Comment 1 Masami Hiramatsu 2007-10-08 16:49:20 UTC
I'm interested in this feature.

As far as I understand, with this feature, systemtap treats the next script ;
---
 probe ALIAS=PROBEPOINT { stmt1; }
 probe ALIAS if (expr) { stmt2; }
---
as
---
 probe PROBEPOINT { if (!expr) next; stmt1; stmt2}
---

In that case, 
---
 probe ALIAS=PROBEPOINT { stmt1; }
 probe ALIAS if (expr) { stmt2; }
 probe ALIAS { stmt3; }
---
will be treated as
---
 probe PROBEPOINT { if (!expr) next; stmt1; stmt2}
 probe PROBEPOINT { stmt1; stmt3}
---
Is that right?
Comment 2 Frank Ch. Eigler 2007-10-08 17:10:18 UTC
> In that case, 
> ---
>  probe ALIAS=PROBEPOINT { stmt1; }
>  probe ALIAS if (expr) { stmt2; }
>  probe ALIAS { stmt3; }
> ---
> will be treated as
> ---
>  probe PROBEPOINT { if (!expr) next; stmt1; stmt2}
>  probe PROBEPOINT { stmt1; stmt3}
> ---
> Is that right?

That's right.  It wouldn't make sense to act as if the conditional
was within the probe handler block (after the prefix from aliases),
since that would require the underlying probe to still be active.

It also means that the variables in "expr" can in practice only involve
global script-level variables.  (Even pure embedded-C functions can
change their values frequently enough to make them impractical as
part of an automatic predicate.  In this sort of case, we could opt
to automatically translate the script to the "{ if (!expr) next; ... }"
form, which would run correctly but slowly.)
Comment 3 Masami Hiramatsu 2007-11-16 23:40:33 UTC
Created attachment 2095 [details]
on-the-fly enable/disable probes patch for parser and elabolator

I developed a patch for the parser and the elabolator to support this syntax.

Currently, this just translates the next script;
---
 probe ALIAS=PROBEPOINT if (expr1) { stmt1 }
 probe ALIAS if (expr2) { stmt2 }
---
to below;
---
 probe PROBEPOINT { 
   if (!((expr2)&&(expr1))) next
   stmt1
   stmt2
 }
---

This patch adds "if (..)" condition to the PROBEPOINT instead of "probe".
So, you can write the below script with this patch;
---
 probe PP1 if (expr1), PP2 if (expr2) {stmt}
---
This is translated to below;
---
 probe PP1 { 
   if (!expr1) next 
   stmt
 }
 probe PP2 {
   if (!expr2) next
   stmt
 }
---

This is the first step of this feature, since this patch does not
include optimization code.

Thanks,
Comment 4 Masami Hiramatsu 2007-11-27 16:02:26 UTC
Created attachment 2110 [details]
A bugfix patch for on-the-fly probe enable/disable syntax

This patch fixes a bug in the previous patch to allow user to access kernel
variables in the condition expression of probe points.
Comment 5 Frank Ch. Eigler 2007-11-27 16:15:39 UTC
(In reply to comment #4)
> This patch fixes a bug in the previous patch to allow user to access kernel
> variables in the condition expression of probe points.

Please note that use of this capability would render the probe un-disableable,
since kernel $context variables need to be evaluated from a single particular
kprobe rather than anywhere in the script.
Comment 6 Masami Hiramatsu 2007-11-27 23:10:37 UTC
(In reply to comment #5)
> Please note that use of this capability would render the probe un-disableable,
> since kernel $context variables need to be evaluated from a single particular
> kprobe rather than anywhere in the script.
> 

Sure, I agree.
I think when we access only global variables in the condition and those 
variables are not changed in the probe point, the probe will be disabled
automagically from other probes where those global variables are changed.
And This optimization depends on where the global variables are changed.
Procfs probes and timer probe are good places to do that.
Comment 7 Masami Hiramatsu 2007-12-04 20:45:48 UTC
Created attachment 2122 [details]
Documentation patch for on-the-fly probe enable/disable syntax

This patch adds comments in manpage and NEWS.
Comment 8 Masami Hiramatsu 2007-12-04 20:47:38 UTC
Created attachment 2123 [details]
Testcases for on-the-fly probe enable/disable syntax

This patch adds testcases for on-the-fly probe enable/disable syntax, which
includes:
- parser tests (ok/ko)
- semantic tests (ok/ko)
- basic functionality test
Comment 9 Frank Ch. Eigler 2007-12-05 17:08:53 UTC
Thank you, these are good to commit.
We can fix minor spelling errors in CVS.
One question regarding the new semko/thirtynine test: why should that fail
rather than be interpreted as an unconditional probe that happens to contain
".if(1)" as the last probe point component?
Comment 10 Masami Hiramatsu 2007-12-05 19:21:03 UTC
(In reply to comment #9)
> One question regarding the new semko/thirtynine test: why should that fail
> rather than be interpreted as an unconditional probe that happens to contain
> ".if(1)" as the last probe point component?

Because the "if()" statement is not a component of a probe point, you should NOT
 use it with ".".

The parser passes ".if(1)" as a probe point component.However, the elaborator
fails to resolve it, so it is "semko".

Here is the error output:
---
semantic error: probe point mismatch at position 2 (alternatives: call inline
return) while resolving probe point kernel.function("sys_open").if(1)
---

Thanks,
Comment 11 Masami Hiramatsu 2008-01-26 15:23:30 UTC
I got following error message with latest systemtap.

$ stap -e 'probe kernel.function("netlink_unicast") if (execname()=="swapper"){
print_backtrace();}'
semantic error: probe condition must not reference function: identifier
'execname' at <input>:1:46
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Why can not we use function or kernel-variables in probepoint condition?
Comment 12 Frank Ch. Eigler 2008-01-26 15:45:33 UTC
> $ stap -e 'probe kernel.function("netlink_unicast") if (execname()=="swapper"){

> Why can not we use function or kernel-variables in probepoint condition?

In this case, the reason is that such expressions can't be optimized in the
sense that probes with such conditions cannot actually be armed/disarmed,
because the translator has no way of knowing when execname() (an embedded-C
function) will change value.

As for pure script functions and such - the current code blocks them out,
but some of that is temporary.  (The reasoning there goes that even to
evaluate expressions containing such function calls, more context space
and statement-counting calculations are necessary.  That's not ideal
considering that 

We did discuss letting the script still more unrestricted condition expressions,
(including embedded-C functions or $target variables), and implement that the 
way your first checkin did: by prepending the condition to the probe handler 
body as if it had been there all along.  (A warning should be produced.)  This 
may well come back.  I just wanted to restrict it for the moment while the 
actual optimization implementation is proceeding.
Comment 13 Frank Ch. Eigler 2008-10-10 20:32:10 UTC
With the syntax already in, what's left is support in the translator
and the runtime for asynchronous kprobe (and in general, other derived_probe)
arming/disarming.

*** This bug has been marked as a duplicate of 6933 ***