From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21423 invoked by alias); 29 Sep 2009 08:58:31 -0000 Received: (qmail 21409 invoked by uid 22791); 29 Sep 2009 08:58:29 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS X-Spam-Check-By: sourceware.org Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (59.145.155.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 08:58:24 +0000 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by e28smtp09.in.ibm.com (8.14.3/8.13.1) with ESMTP id n8T8ot5l023538 for ; Tue, 29 Sep 2009 14:20:55 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8T8wKCD2465910 for ; Tue, 29 Sep 2009 14:28:20 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8T8wKm0021712 for ; Tue, 29 Sep 2009 18:58:20 +1000 Received: from in.ibm.com ([9.124.215.16]) by d28av05.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n8T8wHvP021686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Sep 2009 18:58:19 +1000 Date: Tue, 29 Sep 2009 08:58:00 -0000 From: "K.Prasad" Cc: David Smith , Rajasekhar Duddu , systemtap@sources.redhat.com Subject: Re: [PATCH v2] Tracepoint Tapset for Memory Subsystem Message-ID: <20090929085817.GA7337@in.ibm.com> Reply-To: prasad@linux.vnet.ibm.com References: <20090919050102.GA3767@rajduddu> <4AB90BE0.4030405@redhat.com> <4AB94A1B.4090801@redhat.com> <20090924180817.GA9698@rajduddu> <4ABD17B5.6080500@redhat.com> <1254161548.5107.14.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1254161548.5107.14.camel@localhost.localdomain> User-Agent: Mutt/1.5.19 (2009-01-05) 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-q3/txt/msg00885.txt.bz2 On Mon, Sep 28, 2009 at 11:12:28AM -0700, Jim Keniston wrote: > > On Fri, 2009-09-25 at 14:19 -0500, David Smith wrote: > ... > > > > Sorry to keep finding more things, but... > > > > I'm a bit worried about your use of '__builtin_return_address()' here. > > Jim Keniston reported on it back in 2005 in the following message, but > > there isn't much context. > > > > > > > > Jim, can you remember some context here? Was the use of > > '__builtin_return_address' considered good/bad/neutral? We don't seem > > to use it anywhere else. > > > > In case anybody still cares... > Yes, your explanation actually helped! > The context was that we had recently implemented kretprobes, and > somebody pointed out that hijacking the return address would cause > __builtin_return_address() to return the wrong value. From my survey of > the kernel, I concluded that "__builtin_return_address is used entirely > for tracing (tracing that is disabled by default), profiling, and error > reporting. I couldn't find any case where normal operation of the OS > would be affected." > > Ironically, soon after that, kprobes itself started using > __builtin_return_address(). > > Anyway, there was no controversy as to whether > __builtin_return_address() was bad or good per se; it was simply > recognized that it would return invalid results when called from a > return-probed function. > > Jim > This means that __builtin_return_address() would return incorrect values irrespective of whether it is used inside a kprobe or a tracepoint based probe i.e. "kmem.kfree.kp" or "kmem.kfree.tp". And since the tracepoints export them (through $call_site parameter), I think we can continue to use them in the kprobe based fallback probe too. Thanks, K.Prasad