Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757121AbYHKT25 (ORCPT ); Mon, 11 Aug 2008 15:28:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756838AbYHKT2k (ORCPT ); Mon, 11 Aug 2008 15:28:40 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:40612 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756793AbYHKT2j (ORCPT ); Mon, 11 Aug 2008 15:28:39 -0400 Date: Mon, 11 Aug 2008 15:28:35 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Mathieu Desnoyers cc: LKML , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Andrew Morton , Linus Torvalds , David Miller , Roland McGrath , Ulrich Drepper , Rusty Russell , Jeremy Fitzhardinge , Gregory Haskins , Arnaldo Carvalho de Melo , "Luis Claudio R. Goncalves" , Clark Williams Subject: Re: [PATCH 0/5] ftrace: to kill a daemon In-Reply-To: <20080811182150.GB32207@Krystal> Message-ID: References: <20080808172259.GB8244@Krystal> <20080808174607.GG8244@Krystal> <20080808182104.GA11376@Krystal> <20080808190506.GD11376@Krystal> <20080811182150.GB32207@Krystal> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2428 Lines: 57 On Mon, 11 Aug 2008, Mathieu Desnoyers wrote: > > Hi Steven, > > I'm actually a bit worried about this scheduler-centric approach. The > problem is that any trap that could be generated in the middle of the > 3/2 nops (think of performance counters if the APIC is set as a trap > gate) which would stack an interruptible trap handler on top of those > instructions would lead to having a return IP pointing in the wrong > spot, but because the scheduler would interrupt the trap handler and not > the trapped code, it would not detect this. > > I am not sure wheter we do actually have the possibility to have these > interruptible trap handlers considering the way the kernel sets up the > gates, but I think the "let's figure out where the IP stopped" approach > is a bit complex and fragile. > > Trying to find a fast atomic 5-bytes nop, involving the > microarchitecture guys, seems like a better approach to me. > I agree that the fast atomic 5-byte nop is the optimal approach, but until we have that, we need to do this. I don't think this approach is too complex, I wrote the code in about an hour, and the patch isn't that big. albeit my one bug, which was a CS101 type bug (pointer arithmetic), there wasn't anything to me that was complex. The thing is, I want this to be enabled in a production kernel. If there is a 1 in a million chance that this theoretical bug with the trap happening in a middle of the double nop, it only affects those that enable the tracer. No one else. The code only happens when tracing is being enabled. If we need to put in a non optimal nop in, to replace the call to mcount, this affects everyone. Anyone that has CONFIG_FTRACE on, and never plans on running a trace. If it comes down to slowing everyone down, against hitting a 1 in a million theoretical bug, I'll take my chances on the bug. Again, that code is only performed when tracing is being enabled. That is, when it converts all 20 thousand nops into calls to a tracer function. If the crash happens, it will only happen after tracing has started. Then we can easily point the bug at the tracer. IOW, I do not want to slow down Linus' box. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/