From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22224 invoked by alias); 16 Jan 2007 18:35:47 -0000 Received: (qmail 22215 invoked by uid 22791); 16 Jan 2007 18:35:46 -0000 X-Spam-Status: No, hits=-2.4 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, 16 Jan 2007 18:35:40 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0GIZbml025063 for ; Tue, 16 Jan 2007 13:35:37 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0GIZb2C011297; Tue, 16 Jan 2007 13:35:37 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0GIZaQX031223; Tue, 16 Jan 2007 13:35:37 -0500 Received: from ton.toronto.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 2A3828001CF; Tue, 16 Jan 2007 13:35:36 -0500 (EST) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id l0GIZZs2010265; Tue, 16 Jan 2007 13:35:35 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id l0GIZLLE010261; Tue, 16 Jan 2007 13:35:21 -0500 X-Authentication-Warning: ton.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Mathieu Desnoyers Cc: Richard J Moore , Andrew Morton , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, "Martin J. Bligh" , Christoph Hellwig , Douglas Niehaus , Ingo Molnar , ltt-dev@shafik.org, systemtap@sources.redhat.com, Thomas Gleixner Subject: Re: [PATCH 0/4 update] Linux Kernel Markers - i386 : pIII erratum 49 : XMC References: <20070113054534.GA27017@Krystal> <20070116174158.GA16084@Krystal> From: fche@redhat.com (Frank Ch. Eigler) Date: Tue, 16 Jan 2007 18:35:00 -0000 In-Reply-To: <20070116174158.GA16084@Krystal> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00114.txt.bz2 Mathieu Desnoyers writes: > [...] > It would be nice to push the study of the kprobes debug trap handler so it can > become possible to use it to put breakpoints in trap handlers. For now, kprobes > refuses to insert breakpoints in __kprobes marked functions. However, as we > instrument specific spots of the functions (not necessarily the function entry), > it is sometimes correct to use kprobes on a marker within the function even if > it is not correct to use it in the prologue. [...] It may help to note that the issue with __kprobes attributes is separate from putting probes in the prologue vs. elsewhere. The __kprobes functions are so marked because they can cause infinite regress if probed. Examples are fault handlers that would service vmalloc-related faults, and some other functions unavoidably callable from early probe handling context. Over time, the list has shrunk. Indeed, __kprobes marking is a conservative measure, in that there may be spots in such functions that are immune from recursion hazards. But so far, we haven't encountered enough examples of this to warrant refining this blacklist somehow. - FChE