From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23603 invoked by alias); 21 Mar 2006 22:46:48 -0000 Received: (qmail 23593 invoked by uid 22791); 21 Mar 2006 22:46:48 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from fmr22.intel.com (HELO scsfmr002.sc.intel.com) (143.183.121.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Mar 2006 22:46:47 +0000 Received: from scsfmr100.sc.intel.com (scsfmr100.sc.intel.com [10.3.253.9]) by scsfmr002.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k2LMkckO006878; Tue, 21 Mar 2006 22:46:38 GMT Received: from unix-os.sc.intel.com (unix-os.sc.intel.com [172.25.110.7]) by scsfmr100.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id k2LMkl1a030689; Tue, 21 Mar 2006 22:46:47 GMT Received: (from askeshav@localhost) by unix-os.sc.intel.com (8.11.6/8.11.2) id k2LMkaD31710; Tue, 21 Mar 2006 14:46:36 -0800 Date: Tue, 21 Mar 2006 22:46:00 -0000 From: Keshavamurthy Anil S To: Prasanna S Panchamukhi Cc: Keshavamurthy Anil S , Richard J Moore , systemtap@sources.redhat.com Subject: Re: thoughts about exception-handling requirements for kprobes Message-ID: <20060321144636.A31356@unix-os.sc.intel.com> Reply-To: Keshavamurthy Anil S References: <20060317135057.A18437@unix-os.sc.intel.com> <20060319172454.GA17181@in.ibm.com> <20060320103951.A10565@unix-os.sc.intel.com> <20060320185719.GA3320@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060320185719.GA3320@in.ibm.com>; from prasanna@in.ibm.com on Tue, Mar 21, 2006 at 12:27:19AM +0530 X-Scanned-By: MIMEDefang 2.52 on 10.3.253.9 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/msg00846.txt.bz2 On Tue, Mar 21, 2006 at 12:27:19AM +0530, Prasanna S Panchamukhi wrote: > 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: > > 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. > > > > 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); > > Are you trying to tell here that by allowing preemption() in the > kprobes handler, the above debug message log can be avoided? Not only that, I am asking to relook at kprobes to see if we can reliably support calling pre/post handlers without having to disable preemption. (I am aware that currently the lock-free RCU changes depends on the fact that handlers are run with preempt disabled) If we can acheive calling pre/post handlers without having to disable preempt then the benifit of this work is huge. > > > > > 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. > > We actually do not want to fall back on system do_page_fault() because, > it might sleep. When pre/post handler page faults, we can just try > calling fixup_exception() (non-ia64 architectures) and try to avoid actual > do_page_fault() to be called because it might sleep(). Yes, by fixing up the exceptions(fixup_exception() call) you are avoiding falling back to do_page_fault(), but the copy_from_user() which generated the exception will fail and we can not 100% reliably support copy from user from pre/post handlers even for valid address. Also on a system where memory presure is high we might see lots user address reference from pre/post handlers failing. Is this acceptable solution for Systemtap? Do we know how reliable is Dtrace in this respect? Thanks, Anil