From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30500 invoked by alias); 19 Mar 2006 17:24:34 -0000 Received: (qmail 30493 invoked by uid 22791); 19 Mar 2006 17:24:34 -0000 X-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_05,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 19 Mar 2006 17:24:32 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2JHOU3B002375 for ; Sun, 19 Mar 2006 12:24:30 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2JHLXYD273862 for ; Sun, 19 Mar 2006 10:21:33 -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 k2JHOULw011084 for ; Sun, 19 Mar 2006 10:24:30 -0700 Received: from newton.in.ibm.com ([9.124.88.202]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k2JHOSUl011049; Sun, 19 Mar 2006 10:24:29 -0700 Received: by newton.in.ibm.com (Postfix, from userid 500) id BC3BACE8; Sun, 19 Mar 2006 22:54:54 +0530 (IST) Date: Sun, 19 Mar 2006 17:24:00 -0000 From: Prasanna S Panchamukhi To: Keshavamurthy Anil S Cc: Richard J Moore , systemtap@sources.redhat.com Subject: Re: thoughts about exception-handling requirements for kprobes Message-ID: <20060319172454.GA17181@in.ibm.com> Reply-To: prasanna@in.ibm.com References: <20060317135057.A18437@unix-os.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060317135057.A18437@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/msg00828.txt.bz2 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? Thanks Prasanna > > > > 2) Unexpected exception, user pre-handler. > > > > here the pre-handler has either a bug or is debugging a badly damaged > > environment. Let's not forget that the latter environment is very > > import to > > cater for as best we can. > > The response should at the very least be to quietly cancel the > > pre-handler. > > It's also conceivable that one might want to intercept this to free > > off any > > locks and put out an explanatory message. > > Yes, it would be nice to recover even from a buggy pre/post_handler and > disable the buggy probe completly with some explanatory message. > > > Thanks, > Anil -- Prasanna S Panchamukhi Linux Technology Center India Software Labs, IBM Bangalore Email: prasanna@in.ibm.com Ph: 91-80-51776329