From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10034 invoked by alias); 11 Jun 2007 20:18:29 -0000 Received: (qmail 10025 invoked by uid 22791); 11 Jun 2007 20:18:27 -0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,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; Mon, 11 Jun 2007 20:18:15 +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 l5BKIDwl002292 for ; Mon, 11 Jun 2007 16:18:13 -0400 Received: from gateway.sf.frob.com (vpn-14-189.rdu.redhat.com [10.11.14.189]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5BKICeh018288; Mon, 11 Jun 2007 16:18:12 -0400 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 41804357B; Mon, 11 Jun 2007 13:18:11 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id BE7724D05B5; Mon, 11 Jun 2007 13:18:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Keniston X-Fcc: ~/Mail/utrace Cc: systemtap Subject: Re: updated uprobes patches In-Reply-To: Jim Keniston's message of Tuesday, 29 May 2007 15:24:20 -0700 <1180477460.3889.61.camel@ibm-ni9dztukfq8.beaverton.ibm.com> X-Zippy-Says: Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED! Message-Id: <20070611201810.BE7724D05B5@magilla.localdomain> Date: Mon, 11 Jun 2007 20:18:00 -0000 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: 2007-q2/txt/msg00565.txt.bz2 > 1. __put_task_struct() wasn't exported, so uprobes couldn't call > put_task_struct(). You should not need this. The intent is that utrace facilities give you all the synchronization you need. At cold attach time, things are admittedly a little sketchy, but rcu_read_lock may be all you need. In report_clone the child can't go anywhere until your callback returns. Let me know if you don't think this is clear in the documentation. I don't want to dwell too much on the life-cycle tracking details. In the long run I expect all of that to be handled by another component so the full complexity of the picture won't be your problem. In the immediate term, it's not hard to get it going well enough for experimentation. Not every corner has to be covered to make something to develop with. > 2. access_process_vm() wasn't exported, so uprobes couldn't call that. get_user_pages is. It is more efficient to use a single read-copy-write done with get_user_pages et al than separate access_process_vm calls anyway. I may come up with some convenience functions related to this eventually. But the code is short, doing it directly is just a few minutes' work. > 3. I couldn't figure out how to build a module consisting of > kernel/uprobes.o and arch/i386/kernel/uprobes.o. (So I put 'em both in > the same directory for my experiment.) I'm not going to worry about build trivia for the moment, just the code. That sort of issue can always be worked out one way or another. > Er, do Fedora kernels export access_process_vm() and > __put_task_struct()? (I'm currently running a kernel.org kernel.) If > not, is it still worthwhile to modularize uprobes? I think we are approaching the discussion from rather different points of view. I mentioned immediate ease of development because I thought it would be motivational for you, not because it is my own primary motivation behind my arguments. The basis of my view is that utrace exists to enable the implementation of things just like uprobes without further modifications to the core kernel. When that is difficult, it points to needs for improvements in the utrace API, or for components to build on top of it. My real motivation is the general growth of the infrastructure and ecology of such components. Frankly, I am not very interested in implementation details of uprobes per se, which I consider a prototype in its basic structure. This is why I began the separate thread of discussion on a few detailed subtopics of "breakpoint assistance". My own interest is in the robust fleshing out of the "interesting" components of that work, like truly robust instruction decoding. > Current practice is to deallocate the uprobe_process graph when the > count of registered probes hits zero. If the uprobe_process graph > becomes the only place to remember where the SSOL vma lives, I think the > path of least resistance is to discard (munmap) the SSOL vma along with > the uprobe_process. (Haven't tried that yet.) Yes, that is what I meant to imply as the natural "unoptimized" plan. Thanks, Roland