public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "wenji dot huang at oracle dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sources.redhat.com
Subject: [Bug translator/6711] need script syntax for extending blacklist
Date: Fri, 22 Jan 2010 05:46:00 -0000	[thread overview]
Message-ID: <20100122054630.15079.qmail@sourceware.org> (raw)
In-Reply-To: <20080630230203.6711.fche@redhat.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.

  parent reply	other threads:[~2010-01-22  5:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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
     [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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100122054630.15079.qmail@sourceware.org \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).