From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20692 invoked by alias); 7 Feb 2006 20:48:31 -0000 Received: (qmail 20685 invoked by uid 22791); 7 Feb 2006 20:48:31 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Feb 2006 20:48:29 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k17KmQ92009128 for ; Tue, 7 Feb 2006 15:48:26 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k17KmQ104309; Tue, 7 Feb 2006 15:48:26 -0500 Received: from vpn83-156.boston.redhat.com (vpn83-156.boston.redhat.com [172.16.83.156]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k17KmPYT007707; Tue, 7 Feb 2006 15:48:25 -0500 Subject: RE: kprobe fault handling From: Martin Hunt To: "Keshavamurthy, Anil S" Cc: Jim Keniston , "systemtap@sources.redhat.com" In-Reply-To: <44BDAFB888F59F408FAE3CC35AB4704102F4F1A3@orsmsx409> References: <44BDAFB888F59F408FAE3CC35AB4704102F4F1A3@orsmsx409> Content-Type: text/plain Organization: Red Hat Inc Date: Tue, 07 Feb 2006 20:48:00 -0000 Message-Id: <1139345364.4168.20.camel@monkey2> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-25) Content-Transfer-Encoding: 7bit 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/msg00411.txt.bz2 On Tue, 2006-02-07 at 12:35 -0800, Keshavamurthy, Anil S wrote: > >I just had a long chat with Richard Moore about this whole topic. I > >agree with you on this, and I think Richard would, too. > > > >So unless there's a user-specified handler and that handler specifies > >(by returning 1) that it has handled the exception, > >kprobe_fault_handler() should run fixup_exception(), right? > > > >Now I'm looking, later in that function, at the code (on i386) where we > >handle an exception while single-stepping. I don't think > >resume_execution() is the right thing to do here. We haven't > >successfully executed the probed instruction, and the eip still points > >at that instruction, right? I think we're just hosed at this point. > >Comments? > I agree with your comments and we need a better fix. > Currently for RHEL4 release I am inclined to remove > DIE_PAGE_FAULT switch case as this at least improves > the performance. Anil. Did you read this thread, starting at http://sources.redhat.com/ml/systemtap/2006-q1/msg00392.html How will removing page fault handling fix our broken page fault handling? Martin