From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18117 invoked by alias); 19 Jun 2009 01:56:09 -0000 Received: (qmail 18108 invoked by uid 22791); 19 Jun 2009 01:56:08 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 01:56:00 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5J1tuqs029920; Thu, 18 Jun 2009 21:55:56 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5J1ttNo018379; Thu, 18 Jun 2009 21:55:55 -0400 Received: from [10.3.224.172] (vpn-224-172.phx2.redhat.com [10.3.224.172]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5J1tsgq020296; Thu, 18 Jun 2009 21:55:55 -0400 Message-ID: <4A3AF02A.4070008@redhat.com> Date: Fri, 19 Jun 2009 01:56:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b5pre) Gecko/20090513 Fedora/3.0-2.4.b3pre.hg.6a6386c16e98.fc11 Lightning/1.0pre Thunderbird/3.0b3pre MIME-Version: 1.0 To: Przemyslaw Pawelczyk CC: systemtap@sourceware.org Subject: Re: [PATCH 2/2] Add test for target_set tapset. References: <1244936781.212635.16785@debian> <1245365912.847583.942@debian> In-Reply-To: <1245365912.847583.942@debian> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2009-q2/txt/msg00963.txt.bz2 On 06/18/2009 03:33 PM, Przemyslaw Pawelczyk wrote: > +proc abort {} { > + global test > + fail $test > + exit > +} exit should not be used, because that will stop the entire testing session. We don't want failure here to prevent other tests from running. > + set pid_it $stp_pid > + while {[info exists pid_array($pid_it)]} { > + if {[exec pgrep -P $pid_it] != $pid_array($pid_it)} { > + abort > + } > + set pid_it $pid_array($pid_it) > + } There's a race here that the sleep process might finish before pgrep sees it. Most of the time, one second will probably be plenty of time, but on a slow and/or loaded system we could have false failures. What if you just used an absurdly long timeout for sleep, and then "kill -INT" it after you've verified the chain? > +probe nd_syscall.nanosleep > +{ > + if (target_set_pid(pid()) && @cast(req_uaddr, "timespec", "")->tv_sec == $1) > + target_set_report() > +} Some systems have a 32-bit userspace with a 64-bit kernel, and in that case you would need to catch nd_syscall.compat_nanosleep as well. I feel like you're going through somewhat heroic efforts to validate this in tcl, and you're not able to use any of the common infrastructure we have for other tests. Maybe it would easier to check results within the script? We couldn't check the report() that way, but target_set_pid() is what we really care about anyway, right? I'm imagining that in the nanosleep probe, you could recursively walk up task_parent() until you hit stp_pid() or 1 (init). Then as the recursion unwinds, make sure that target_set_pid() matches. You can use system() to also launch a sleep that's outside of the target_set. Does that make sense? Josh