From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22760 invoked by alias); 11 May 2007 22:31:28 -0000 Received: (qmail 22750 invoked by uid 22791); 11 May 2007 22:31:27 -0000 X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 May 2007 22:31:25 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4BMVBW7028520 for ; Fri, 11 May 2007 18:31:11 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4BMUJZ5028063; Fri, 11 May 2007 18:31:05 -0400 Received: from pasta.boston.redhat.com (pasta.boston.redhat.com [172.16.80.54]) by mail.boston.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l4BM2g2i027499; Fri, 11 May 2007 18:02:42 -0400 Received: from pasta.boston.redhat.com (localhost.localdomain [127.0.0.1]) by pasta.boston.redhat.com (8.12.8/8.12.8) with ESMTP id l4BM6PYK013625; Fri, 11 May 2007 18:06:25 -0400 Received: from pasta.boston.redhat.com (ernie@localhost) by pasta.boston.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id l4BM6P9Z013621; Fri, 11 May 2007 18:06:25 -0400 Message-Id: <200705112206.l4BM6P9Z013621@pasta.boston.redhat.com> To: Jim Keniston cc: "Frank Ch. Eigler" , Linda Wang , systemtap@sources.redhat.com Subject: Re: [RFC][PATCH 2/2] uprobes: single-step out of line In-Reply-To: Your message of "Thu, 10 May 2007 15:17:44 PDT." <1178835464.3753.18.camel@ibm-ni9dztukfq8.beaverton.ibm.com> Date: Fri, 11 May 2007 22:31:00 -0000 From: Ernie Petrides 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: 2007-q2/txt/msg00263.txt.bz2 On Thursday, 10-May-2007 at 15:17 PDT, Jim Keniston wrote: > On Tue, 2007-05-08 at 21:34 -0400, Ernie Petrides wrote: > > > I'm not sure what the best solution is. Maybe what you've already > > got here is reasonable. I'd need to study mm_struct compatibility > > issues for a while to determine if this would be a deal-breaker in > > terms of the kABI issue. (We have this "#ifndef __GENKSYMS__" hack > > that can sometimes be used to accommodate these sorts of structure > > additions in a RHEL update to avoid the symbol checksum change, but > > it's only viable if there's no true underlying compatibility problem.) > > > Yes, I'd appreciate it if you confirm the need for a change here, since > the effort/implications for this change are non-trivial. I've researched "mm_struct" usage in the latest RHEL5 kernel sources, specifically looking for dependencies on the structure size and on the offsets to the fields beyond the "mm_context_t". As far as I can see, all of these dependencies are in the base part of the kernel (as opposed to modules). This suggest that the __GENKSYMS__ hack could be used to hide your new "uprobes_ssol_area" field being added to the "mm_context_t" (to preserve exported symbol versioning) without causing a true binary compatibility problem. That being said, I don't represent views of the RHEL5 kernel maintainer nor any other senior developers who might have to sign off on such a change in the hypothetical scenario of a uprobes back-port to RHEL5. But using __GENKSYMS__ for this situation looks safe to me. Obviously, this is a non-issue for upstream acceptance, since all sources are expected to be recompiled (and thus there is no attempt to preserve kABI). I did notice, however, that the "dumpable" field of the "mm_struct" comes after the "mm_context_t" upstream in 2.6.21 (unlike in RHEL5). Some other distro based on a more recent upstream version could conceivably have an issue with this field, since it's remotely possible (though unlikely) that a 3rd-party exec format handler or security module might access "dumpable" (whose field offset would change with an "mm_context_t" addition). But this is a somewhat far-fetched example, so all in all, you're probably okay. Cheers. -ernie