* [Bug translator/6711] need script syntax for extending blacklist
[not found] <bug-6711-6586@http.sourceware.org/bugzilla/>
@ 2023-05-25 20:49 ` fche at redhat dot com
2023-05-31 2:01 ` libo.ch at gmail dot com
1 sibling, 0 replies; 11+ messages in thread
From: fche at redhat dot com @ 2023-05-25 20:49 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <bug-6711-6586@http.sourceware.org/bugzilla/>
2023-05-25 20:49 ` [Bug translator/6711] need script syntax for extending blacklist fche at redhat dot com
@ 2023-05-31 2:01 ` libo.ch at gmail dot com
1 sibling, 0 replies; 11+ messages in thread
From: libo.ch at gmail dot com @ 2023-05-31 2:01 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
` (7 preceding siblings ...)
2010-02-10 2:10 ` jistone at redhat dot com
@ 2010-02-10 2:15 ` jistone at redhat dot com
8 siblings, 0 replies; 11+ messages in thread
From: jistone at redhat dot com @ 2010-02-10 2:15 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
` (6 preceding siblings ...)
2010-01-25 7:52 ` wenji dot huang at oracle dot com
@ 2010-02-10 2:10 ` jistone at redhat dot com
2010-02-10 2:15 ` jistone at redhat dot com
8 siblings, 0 replies; 11+ messages in thread
From: jistone at redhat dot com @ 2010-02-10 2:10 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
` (5 preceding siblings ...)
2010-01-22 5:46 ` wenji dot huang at oracle dot com
@ 2010-01-25 7:52 ` wenji dot huang at oracle dot com
2010-02-10 2:10 ` jistone at redhat dot com
2010-02-10 2:15 ` jistone at redhat dot com
8 siblings, 0 replies; 11+ messages in thread
From: wenji dot huang at oracle dot com @ 2010-01-25 7:52 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
` (4 preceding siblings ...)
2010-01-21 20:22 ` jistone at redhat dot com
@ 2010-01-22 5:46 ` wenji dot huang at oracle dot com
2010-01-25 7:52 ` wenji dot huang at oracle dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: wenji dot huang at oracle dot com @ 2010-01-22 5:46 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
` (3 preceding siblings ...)
2010-01-21 3:21 ` wenji dot huang at oracle dot com
@ 2010-01-21 20:22 ` jistone at redhat dot com
2010-01-22 5:46 ` wenji dot huang at oracle dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: jistone at redhat dot com @ 2010-01-21 20:22 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
` (2 preceding siblings ...)
2010-01-19 12:00 ` fche at redhat dot com
@ 2010-01-21 3:21 ` wenji dot huang at oracle dot com
2010-01-21 20:22 ` jistone at redhat dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: wenji dot huang at oracle dot com @ 2010-01-21 3:21 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
2008-08-28 18:41 ` mhiramat at redhat dot com
2010-01-19 8:49 ` wenji dot huang at oracle dot com
@ 2010-01-19 12:00 ` fche at redhat dot com
2010-01-21 3:21 ` wenji dot huang at oracle dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: fche at redhat dot com @ 2010-01-19 12:00 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
2008-08-28 18:41 ` mhiramat at redhat dot com
@ 2010-01-19 8:49 ` wenji dot huang at oracle dot com
2010-01-19 12:00 ` fche at redhat dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: wenji dot huang at oracle dot com @ 2010-01-19 8:49 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug translator/6711] need script syntax for extending blacklist
[not found] <20080630230203.6711.fche@redhat.com>
@ 2008-08-28 18:41 ` mhiramat at redhat dot com
2010-01-19 8:49 ` wenji dot huang at oracle dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 11+ messages in thread
From: mhiramat at redhat dot com @ 2008-08-28 18:41 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-05-31 2:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-6711-6586@http.sourceware.org/bugzilla/>
2023-05-25 20:49 ` [Bug translator/6711] need script syntax for extending blacklist fche at redhat dot com
2023-05-31 2:01 ` libo.ch at gmail dot com
[not found] <20080630230203.6711.fche@redhat.com>
2008-08-28 18:41 ` mhiramat at redhat dot com
2010-01-19 8:49 ` wenji dot huang at oracle dot com
2010-01-19 12:00 ` fche at redhat dot com
2010-01-21 3:21 ` wenji dot huang at oracle dot com
2010-01-21 20:22 ` jistone at redhat dot com
2010-01-22 5:46 ` wenji dot huang at oracle dot com
2010-01-25 7:52 ` wenji dot huang at oracle dot com
2010-02-10 2:10 ` jistone at redhat dot com
2010-02-10 2:15 ` jistone at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).