From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30915 invoked by alias); 20 Feb 2006 05:07:31 -0000 Received: (qmail 30813 invoked by uid 22791); 20 Feb 2006 05:07:30 -0000 X-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_ABUSE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Feb 2006 05:07:28 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1K57QfJ004912 for ; Mon, 20 Feb 2006 00:07:26 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1K5A1x0191900 for ; Sun, 19 Feb 2006 22:10:03 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k1K57Ohr013248 for ; Sun, 19 Feb 2006 22:07:24 -0700 Received: from newton.in.ibm.com ([9.124.35.47]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1K57MDP013155; Sun, 19 Feb 2006 22:07:23 -0700 Received: by newton.in.ibm.com (Postfix, from userid 500) id 9AFB8CE3; Mon, 20 Feb 2006 10:38:56 +0530 (IST) Date: Mon, 20 Feb 2006 05:07:00 -0000 From: Prasanna S Panchamukhi To: "Zhang, Yanmin" Cc: systemtap@sources.redhat.com Subject: Re: [3/3] Userspace probes prototype-take2 Message-ID: <20060220050856.GB4323@in.ibm.com> Reply-To: prasanna@in.ibm.com References: <99FA2ED298A9834DB1BF5DE8BDBF24132B52A7@pdsmsx403> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <99FA2ED298A9834DB1BF5DE8BDBF24132B52A7@pdsmsx403> User-Agent: Mutt/1.4.1i 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-q1/txt/msg00565.txt.bz2 Yanmin, On Mon, Feb 20, 2006 at 11:32:31AM +0800, Zhang, Yanmin wrote: > >>-----Original Message----- > >>From: Zhang, Yanmin > >>Sent: 2006年2月20日 11:16 > >>To: Zhang, Yanmin; prasanna@in.ibm.com; systemtap@sources.redhat.com > >>Subject: RE: [3/3] Userspace probes prototype-take2 > >> > >>I lost an important comment. The patch is not aware of signal processing. After kernel prepares the single-step-inst on the stack, if > >>a signal is delivered to the thread, kernel will save some states into stack and switch to signal handler function, so single-step-inst > >>on the stack might be erased. > >> > >>>>-----Original Message----- > >>>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Zhang, Yanmin > >>>>Sent: 2006年2月17日 17:20 > >>>>To: prasanna@in.ibm.com; systemtap@sources.redhat.com > >>>>Subject: RE: [3/3] Userspace probes prototype-take2 > >>>> > >>>>2 main issues: > >>>>1) task switch caused by external interrupt when single-step; > [YM] I think we could resolve this problem. Kernel probe has some differences from uprobe. One of them is that we couldn't estimate if kernel probe happens in process context, or interrupt context, while uprobe always happens in process context (user space). So from some points of view, uprobe could be simplified from kernel probe. > a) Don't use kcb (kprobe_ctlblk) if uprobe is triggered. Create new functions, kprobe__handler_user, kprobe_fault_handler_user and other handlers. In the new functions, instead of kcb, we could use uprobe_page being allocated dynamically . Yes, I am trying to seperate out kprobes_handlers and uprobe_handlers since user space probe handlers can preempt and might sleep. also given that we might preempt, we cannot reuse the kprobe_handlers() that use rcu. My next take will address this issues. > Considering signal action handler (possible uprobe nested), a thread might have a list of uprobe_page. Yes, reentrancy in this situation also need to be handled. > b) Delete current_uprobe; > > > > >>>>2) multi-thread: > [YM] We could resolve this problem. > a) Don't call replace_orignal_insn in function uprobe_single_step. It might cause a race condition. > b) Delete copy_insn_on_new_page; > c) Merge copy_insn_onstack and copy_insn_onexpstack. The single-step-insn address could be esp-sizeof(long long)-MAX_INSN_SIZE*sizeof(kprobe_opcode_t). This can be done. > d) If the stack couldn't be expanded, just kill the thread. It's reasonable because the stack is used up. We need to take a closer look at this issue > > > >>>> > >>>>See below inline comments. > >>>> > >>>>Yanmin > >>>> > >>>>>>-----Original Message----- > >>>>>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Prasanna S Panchamukhi > >>>>>>Sent: 2006年2月8日 22:14 > >>>>>>To: systemtap@sources.redhat.com > >>>>>>Subject: Re: [3/3] Userspace probes prototype-take2 > >>>>>> > >>>>>> > >>>>>>This patch handles the executing the registered callback > >>>>>>functions when probes is hit. -- Prasanna S Panchamukhi Linux Technology Center India Software Labs, IBM Bangalore Email: prasanna@in.ibm.com Ph: 91-80-51776329