When we find another unsafe-to-probe region, it is inconvenient to recompile the translator just to add a line to the blacklist regexps. It would be nice if there was a syntax for adding blacklist entries on the fly, as a part of the tapset or even separately distributed as an emergency fix. A syntax like this would avoid new tokens: ~ probe PROBEPOINT A possible implementation would be to resolve PROBEPOINT to a derived_probe as usual (assuming an empty handler), but would submit it specially to the derived_probe_group. When it's time to emit all the probes into C code, the derived_probe_group could look for an intersection between the two sets, and spit out an error. (Using the existing alias mechanism: probe SOMETHING.BLACKLISTED = never { $trigger_an_error = 0 } would not work since wildcards can't appear on the LHS.)
*** Bug 6855 has been marked as a duplicate of this bug. ***
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".
(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.
Created attachment 4544 [details] 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.
(In reply to comment #4) > Created an attachment (id=4544) > 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.
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.
Created attachment 4553 [details] 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") */
(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.
(In reply to comment #8) > If the probe builder new that it was "deriving" a noprobe, I must be tired... ^knew
no such serious need has arisen
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.