[Bug translator/6711] need script syntax for extending blacklist

[Bug translator/6711] need script syntax for extending blacklist

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2008-08-28 18:39 -------
*** Bug 6855 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mhiramat at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2010-01-19 08:48 -------
How about the following way, add one option like --black-files.

$./stap -p2 -e 'probe kernel.function("sys_open"){}' --black-files "fs/open.c"
semantic error: no match while resolving probe point kernel.function("sys_open")
Pass 2: analysis failed.  Try again with another '--vp 01' option.

Multi files are separated with "|", for example  "fs/open.c|fs/close.c".

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-01-19 11:59 -------
(In reply to comment #2)
> How about the following way, add one option like --black-files.
> $./stap -p2 -e 'probe kernel.function("sys_open"){}' --black-files "fs/open.c"

It would be better to have a script-level syntax for this, as the database
of blacklisted functions/files is likely to be architecture- & version-sensitive,
thus rely on the preprocessor conditionals.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2010-01-21 03:21 -------
Created an attachment (id=4544)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4544&action=view)
Updated patch

Provide new keyword "fobid" to define those forbidden probe, also
permit mistake in declaration

Example:
$ cat /tmp/1.stp

global i

forbid kernel.function("sys_w*"), kernel.function("no_such")

probe kernel.function("sys_write") {
println("wrong")
exit()
}

probe kernel.function("sys_read") {
println("read")
i++
if (i==10)
  exit()
}
$ sudo ./stap -v /tmp/1.stp
Pass 1: parsed user script and 66 library script(s) using
19380virt/11996res/2064shr kb, in 290usr/90sys/1052real ms.
Pass 2: analyzed script: 2 probe(s), 1 function(s), 0 embed(s), 1 global(s)
using 151584virt/94252res/69620shr kb, in 620usr/370sys/2296real ms.
Pass 3: translated to C into
"/tmp/stapRiEEEE/stap_b9885eca01bebd2a8ff16a3ae4a3e8e1_890.c" using
151584virt/95372res/70740shr kb, in 970usr/90sys/1122real ms.
Pass 4: compiled C into "stap_b9885eca01bebd2a8ff16a3ae4a3e8e1_890.ko" in
6990usr/4990sys/19043real ms.
Pass 5: starting run.
read
read
read
read
read
read
read
read
read
read
Pass 5: run completed in 10usr/70sys/434real ms.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-01-21 20:22 -------
(In reply to comment #4)
> Created an attachment (id=4544)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4544&action=view)
> Updated patch

s/forbidded/forbidden/ throughout the patch.

> 
> Provide new keyword "fobid" to define those forbidden probe, also
> permit mistake in declaration
> 
> Example:
> $ cat /tmp/1.stp
> 
> global i
> 
> forbid kernel.function("sys_w*"), kernel.function("no_such")

I'm not sure that I like "forbid" as a keyword... maybe "noprobe" would be
better (along the lines of the original "~probe" suggestion).

Also, if I understand your patch, it will only work if the forbidden probes are
listed in the primary script (and possibly tapset files that are included
incidentally).  We need this to have a global effect, so any defined in a tapset
blacklist will do their job.

> probe kernel.function("sys_write") {
> println("wrong")
> exit()
> }

If "sys_write" is blocked, then this probe should be an error as it has no
resolved probepoints.  This needs to be an error in pass-2, otherwise, the '?'
and '!' probe resolution won't work correctly.  Listing mode should also not
report probes that would be blocked.

I suggest parsing the forbidden probes immediately into a session global list. 
Resolve those before anything else, so you have a blacklist to compare against
while resolving the real probes.


Something else to think about -- the existing blacklist is able to block probes
based on the function name or filename, regardless of where the probe is in that
function or file.  As it stands, this "forbid" definition is only blocking exact
address matches, which is not as useful IMO.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2010-01-22 05:46 -------
Thanks for your review
> I'm not sure that I like "forbid" as a keyword... maybe "noprobe" would be
> better (along the lines of the original "~probe" suggestion).

Taken
> 
> Also, if I understand your patch, it will only work if the forbidden probes are
> listed in the primary script (and possibly tapset files that are included
> incidentally).  We need this to have a global effect, so any defined in a tapset
> blacklist will do their job.

Yes, should be global
> 
> > probe kernel.function("sys_write") {
> > println("wrong")
> > exit()
> > }
> 
> If "sys_write" is blocked, then this probe should be an error as it has no
> resolved probepoints.  This needs to be an error in pass-2, otherwise, the '?'
> and '!' probe resolution won't work correctly.  Listing mode should also not
> report probes that would be blocked.
> 
> I suggest parsing the forbidden probes immediately into a session global list. 
> Resolve those before anything else, so you have a blacklist to compare against
> while resolving the real probes.
> 
> 
> Something else to think about -- the existing blacklist is able to block probes
> based on the function name or filename, regardless of where the probe is in that
> function or file.  As it stands, this "forbid" definition is only blocking exact
> address matches, which is not as useful IMO.

Current method is to derive the probe and noprobes to detailed single probe
list, and then to match the module and address, so no matter the probe or 
noprobe declared in any forms, like "*@kernel/sched.c". The final list will be
tuiple like
        "kernel, addr1, pp_name, etc." 
It can certainly block those probes in noprobes list.

Ofcourse, the drawback is wasted time and space. As you suggested, maybe
to do regular expression matching before deriving probe is better.

I am figuring out the suitable way to implement blacklist. Any suggestion
or comments are welcome.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2010-01-25 07:52 -------
Created an attachment (id=4553)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4553&action=view)
patch v2

According to the top words on the bug page, seems no
intention to replace current static black list, just additional 
script-syntax adding entries on the fly.

Updated patch is to achieve that. Currently it only filters
dwarf_derived_probe,
easy to extend other probe types. Also Api function defined on tapset is
convenient.

$ ./stap -l 'kernel.function("sys_write*")'
kernel.function("sys_write@fs/read_write.c:390")
kernel.function("sys_writev@fs/read_write.c:714")

$ cat /tmp/noprobe.stp 
noprobe kernel.function("sys_writev"), kernel.function("no_such")

probe kernel.function("sys_write*") {}

probe process("/home/wjhuang/systemtap/stap").function("main"){}

$ ./stap -wp2 /tmp/noprobe.stp 
# probes
kernel.function("sys_write@fs/read_write.c:390") /* pc=_stext+0xf39f5 */ /* <-
kernel.function("sys_write*") */
process("/home/wjhuang/systemtap/stap").function("main@/home/wjhuang/systemtap/main.cxx:439")
/* pc=.absolute+0x40acd0 */ /* <-
process("/home/wjhuang/systemtap/stap").function("main") */

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #4544 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-02-10 02:10 -------
(In reply to comment #6)
> I am figuring out the suitable way to implement blacklist. Any suggestion
> or comments are welcome.

Maybe it's the wrong approach to fully resolve noprobes to real probe points. 
If the probe builder new that it was "deriving" a noprobe, it could just save
the parameters into its dynamic blacklist patterns, without actually resolving
anything.

As each real probe is resolved, they can just be pattern-matched against globs
in the blacklisted (module,function,[source,line]) tuples.

I think this way we could be just as expressive as our current regexes.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-02-10 02:15 -------
(In reply to comment #8)
> If the probe builder new that it was "deriving" a noprobe, 
I must be tired...     ^knew

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/6711] need script syntax for extending blacklist

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=6711

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #10 from Frank Ch. Eigler <fche at redhat dot com> ---
no such serious need has arisen

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/6711] need script syntax for extending blacklist

[libo.ch at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=6711

--- Comment #11 from libo.ch at gmail dot com ---
Removed

fche at redhat dot com via Systemtap <systemtap@sourceware.org>
于2023年5月26日周五 04:50写道：

> https://sourceware.org/bugzilla/show_bug.cgi?id=6711
>
> Frank Ch. Eigler <fche at redhat dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|---                         |OBSOLETE
>
> --- Comment #10 from Frank Ch. Eigler <fche at redhat dot com> ---
> no such serious need has arisen
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.