From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23736 invoked by alias); 22 Sep 2006 09:43:54 -0000 Received: (qmail 23718 invoked by uid 22791); 22 Sep 2006 09:43:52 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ausmtp05.au.ibm.com (HELO ausmtp05.au.ibm.com) (202.81.18.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Sep 2006 09:43:46 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp05.au.ibm.com (8.13.6/8.13.6) with ESMTP id k8M9jvZm2109558 for ; Fri, 22 Sep 2006 19:45:57 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8M9klsb207400 for ; Fri, 22 Sep 2006 19:46:59 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8M9dvA4013128 for ; Fri, 22 Sep 2006 19:39:57 +1000 Received: from [127.0.0.1] ([9.181.133.94]) by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8M9dopS012995; Fri, 22 Sep 2006 19:39:54 +1000 Message-ID: <4513B0C9.6000905@cn.ibm.com> Date: Fri, 22 Sep 2006 09:43:00 -0000 From: Li Guanglei Organization: IBM CSTL User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Vara Prasad CC: Martin Hunt , "Frank Ch. Eigler" , systemtap@sources.redhat.com Subject: Re: whitelist for safe-mode probes (or just a better blacklist?) References: <1158683336.10983.27.camel@dragon> <1158766960.6220.13.camel@dragon> <45116AE2.2060003@us.ibm.com> In-Reply-To: <45116AE2.2060003@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00701.txt.bz2 Vara Prasad wrote: > Martin Hunt wrote: > > > It shouldn't be that difficult to use DWARF library to generate all > exported functions in the kernel. I am only focusing on exported > functions first as their interfaces are more stable then some internal > functions but this method can work on any function. If there happens to > be a function if one of our tapsets is probing that is not in the above > list we should add those functions as well. Once we have the function > names, generate a script that puts probes in some percentage of the > probes let us say 10% at each time in a sliding window. Loads the > generated module and runs a standard test like ltp for 10 mins. The > content of the probe handler should be to print the name of the > function, increment a counter and also print some golbal variables like > PID, GID etc. After being done with the whole list of the functions we > should then generate a script that puts the probe in all the functions > in the white list and runs few standard tests like ltp, fstest etc for > 30 min to make sure probing all of the functions doesn't cause any > instability problems. > > Once we agree upon a format we can run these tests as part of the weekly > test we are doing so we can catch problems early. Over a period of few > weeks we can come up with a decent list that we feel comfortable. Once > we have a big enough of safe list translator by default for wild card > expansion consult this black list and white list and expand only to the > function names from this list. We should also provide a way for us to > indicate the translator i am testing i don't want you to restrict to > only white list so do the real expansion of wildcards. > > A side effect of this work could be after few weeks of results we can > identify safe to probe routines we could probably even go a head and put > some gcc magic macros in the kernel code itself that gives us info in > the ELF section to say what functions are deemed safe to put probes. > That way over a period of time we may not have to ship separate white > list, but that is for future (now i am day dreaming :-) ). > > Anyone got tomatoes? > > bye, > Vara Prasad > Hi, I used: stap -e 'probe kernel.function("*") {}' -p2 -v | grep "kernel.function" | wc -l, and it shows me 10827 functions will be probed. As suggested, we divide all the functions into groups. The number of group can't be too big since we must the run the test enough long for each group. So there will be quite some functions(~1000 maybe) in each group. How about if one of the groups crashes the kernel? In most cases we can't know which functions cause the problem so we have to shrink the scope by and by to put the functions inside this group gradually into the whitelist, but this will cause a lot of work. A bad situation is that all the groups will crash the kernel. Apparently those groups that pass the tests can't declare all functions contains inside them are safe. Maybe some functions were never triggered during the tests or only were triggered a few times and didn't came across the dead condition. If one day we find probing the whole whitelist crashes the Kernel, we have to take pains to find out which one in the whitelist has the problem. And found a suitable testcase that will trigger all the probes is a hard task. So after thinking about this topic, the whole work may not be an easy task. Maybe finally we find we spent too much time to get the whitelist. Just my random thoughts. - Guanglei