From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25999 invoked by alias); 21 Mar 2006 00:34:01 -0000 Received: (qmail 25975 invoked by uid 22791); 21 Mar 2006 00:34:00 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate2.uk.ibm.com (HELO mtagate2.uk.ibm.com) (195.212.29.135) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Mar 2006 00:33:58 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k2L0Xum9256358 for ; Tue, 21 Mar 2006 00:33:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2L0YJXR222832 for ; Tue, 21 Mar 2006 00:34:19 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k2L0XtA7011081 for ; Tue, 21 Mar 2006 00:33:55 GMT Received: from d06ml065.portsmouth.uk.ibm.com (d06ml065.portsmouth.uk.ibm.com [9.149.38.138]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k2L0XtxW011076 for ; Tue, 21 Mar 2006 00:33:55 GMT In-Reply-To: <20060320103951.A10565@unix-os.sc.intel.com> Subject: Re: thoughts about exception-handling requirements for kprobes Sensitivity: To: systemtap@sources.redhat.com X-Mailer: Lotus Notes Release 6.5.1IBM February 19, 2004 Message-ID: From: Richard J Moore Date: Tue, 21 Mar 2006 00:34:00 -0000 X-MIMETrack: Serialize by Router on D06ML065/06/M/IBM(Release 6.53HF247 | January 6, 2005) at 21/03/2006 00:34:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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/msg00836.txt.bz2 systemtap-owner@sourceware.org wrote on 20/03/2006 18:39:51: > 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. Anil, I have already explained the difficulty caused by allowing pre-emption, namely that the ordering of pre and post single-step events is not necessarily preserved. I explained how we can overcome this by using a hand-crafted per-thread single-step stack. See my append a week or so ago on single-stepping with interrupts enabled. > > Currenlty we are calling users pre_handler() and post_handler() > with preempt disabled. If the user has put a probes on > syscalls, then when his pre/post handlers are called he is > bound to call copy_from_user(), which has a check might_sleep(). > The might_sleep() calls in_atomic() function which checks preempt_count() > and if preempt_count() is greater than zero( in our case it indeed greater > than zero, since we are calling pre/post handlers with preempt disabled) > the kernel prints a error message > printk(KERN_ERR "Debug: sleeping function called from invalid" > " context at %s:%d\n", file, line); > > Also if we want to fallback on do_page_fault() function in > kprobe_fault_handler() to > recover the page, then we should not be in preempt_disabled() state. > > Let me know if you more questions. > > -Anil > > > > >