From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15117 invoked by alias); 22 Jan 2010 05:46:42 -0000 Received: (qmail 15080 invoked by uid 48); 22 Jan 2010 05:46:30 -0000 Date: Fri, 22 Jan 2010 05:46:00 -0000 Message-ID: <20100122054630.15079.qmail@sourceware.org> From: "wenji dot huang at oracle dot com" To: systemtap@sources.redhat.com In-Reply-To: <20080630230203.6711.fche@redhat.com> References: <20080630230203.6711.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/6711] need script syntax for extending blacklist X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00226.txt.bz2 ------- 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.