From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11913 invoked by alias); 21 Mar 2006 05:23:54 -0000 Received: (qmail 11904 invoked by uid 22791); 21 Mar 2006 05:23:53 -0000 X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from e4.ny.us.ibm.com (HELO e4.ny.us.ibm.com) (32.97.182.144) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Mar 2006 05:23:51 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2L5Ndrd014322 for ; Tue, 21 Mar 2006 00:23:39 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2L5NT7U222528 for ; Tue, 21 Mar 2006 00:23:30 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2L5NTpe030797 for ; Tue, 21 Mar 2006 00:23:29 -0500 Received: from thinktux.in.ibm.com ([9.124.35.22]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2L5NRjq030742; Tue, 21 Mar 2006 00:23:28 -0500 Received: from thinktux.in.ibm.com (localhost [127.0.0.1]) by thinktux.in.ibm.com (Postfix) with ESMTP id 9042C12B6E0; Tue, 21 Mar 2006 10:53:16 +0530 (IST) Received: (from ananth@localhost) by thinktux.in.ibm.com (8.12.8/8.12.8/Submit) id k2L5NE2L002683; Tue, 21 Mar 2006 10:53:14 +0530 Date: Tue, 21 Mar 2006 05:23:00 -0000 From: Ananth N Mavinakayanahalli To: Keshavamurthy Anil S Cc: Prasanna S Panchamukhi , Richard J Moore , systemtap@sources.redhat.com Subject: Re: thoughts about exception-handling requirements for kprobes Message-ID: <20060321052314.GA2671@in.ibm.com> Reply-To: ananth@in.ibm.com References: <20060317135057.A18437@unix-os.sc.intel.com> <20060319172454.GA17181@in.ibm.com> <20060320103951.A10565@unix-os.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060320103951.A10565@unix-os.sc.intel.com> 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/msg00838.txt.bz2 On Mon, Mar 20, 2006 at 10:39:51AM -0800, Keshavamurthy Anil S wrote: > On Sun, Mar 19, 2006 at 09:24:54AM -0800, Prasanna S Panchamukhi wrote: > > > > On Fri, Mar 17, 2006 at 01:50:57PM -0800, Keshavamurthy Anil S wrote: > > > On Thu, Mar 09, 2006 at 07:57:18AM -0800, Richard J Moore wrote: > > > > > > > > I've been thinking about the need for exception-handling and > > how the > > > > current implementation has become a little muddled. > > > > > > Here is my thinking on this kprobe fault handling... > > > Ideally we want the ability to recover from all > > > the page faults happening from either pre-handler > > > or happening from post-handler transparently in the > > > same way as the normal kernel would recover from > > > do_page_fault() function. In order for this to happen, > > > I think we should not be calling pre-handler/post-handler > > > by disabling preempt which is a major design change. > > > Also in the current code if fixup_exception() fails to > > > fixup the exception then falling back on the normal > > > do_page_fault() is a bad thing with preempt disabled. > > > > > > I was thinking on this issue for the past several days > > > and I believe that currently we are disabling preempt > > > before calling pre/post handler, because we don;t > > > want the process to get migrated to different CPU > > > and we don't want another process to be scheduled > > > while we are servicing kprobe as the newly scheduled > > > process might trigger another probe and we don;t > > > have space to save the kprobe control block(kprobe_ctlbk) > > > info, because we save kprobe_ctlbk in the per cpu structure. > > > > > > If we move this saving kprobe_ctlbk to task struct then > > > I think we will have the ability to call pre/post-handler > > > without having to disable preempt and their by any faults > > > happening from either pre/post handler can recover transparently > > > in the same way as the normal kernel would recover. > > > > > > > Kprobes user-specified pre/post handler are called within > > the interrupt context and if we allow page faults while within > > user-specified pre/post handler, then it might sleep. > > Is is ok to sleep while within the interrupt handler? > Prasanna, > I am not getting what you are asking here, if you are > asking is it okay to sleep while within the interrupt handler, > then it is BIG NO. > > What I am saying is that we should look into kprobes to see > if we can support calling users pre/post handlers > without having to disable preempt. The fundamental assumption that probes run with preempt disabled is what allowed introduction of RCU for lockless execution. If this is to be changed, we also need a thorough relook at if we can use RCU at all post the change. Ananth