From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757052AbZBWPvw (ORCPT ); Mon, 23 Feb 2009 10:51:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756595AbZBWPv1 (ORCPT ); Mon, 23 Feb 2009 10:51:27 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:39203 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756579AbZBWPv0 (ORCPT ); Mon, 23 Feb 2009 10:51:26 -0500 Date: Mon, 23 Feb 2009 10:51:21 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Mathieu Desnoyers cc: Andi Kleen , linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Thomas Gleixner , Peter Zijlstra , Frederic Weisbecker , Linus Torvalds , Arjan van de Ven , Rusty Russell , "H. Peter Anvin" , Steven Rostedt Subject: Re: [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions In-Reply-To: <20090223154258.GB28727@Krystal> Message-ID: References: <20090220011316.379904625@goodmis.org> <20090220011521.003556651@goodmis.org> <87y6vyuzsn.fsf@basil.nowhere.org> <20090223023332.GA5430@Krystal> <20090223045357.GA9158@Krystal> <20090223154258.GB28727@Krystal> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) 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 On Mon, 23 Feb 2009, Mathieu Desnoyers wrote: > > > > As for RO_DATA and bugs, it is a very small window for this to happen, and > > the sys-admin is the one making the change. This is not some periodical > > update. The sys-admin must be the one to initiate the tracer to modify > > text, ie, enabling or disabling the function tracer. Which, by the way, is > > something a sys-admin should only do when the system is off line. The > > overhead of all functions being traced, would not be something to be > > doing on a production system, unless they need to analyze something going > > wrong. > > > > The argument "not to be used on production systems" is incompatible with > the LTTng view, sorry. If you design your code so it's usable only in > debugging scenarios on development machines and not in the field, then I > doubt LTTng will be able to rely on it. I'm OK with that, as long as > nobody argue that such tracepoint could be replaced by the function > tracer, because tracepoints has to be enabled in the field on production > machines. Please do not confuse ftrace with the function tracer. The stop_machine is only about the function tracer and has nothing to do with the rest of ftrace. This is one detail. Yes, tracing EVERY function in the kernel will add an overhead. There's no way around it. It's OK to do it on a production system, but it WILL add overhead. That's what happens when you trace EVERY function. Note, I leave a lot of the other tracers on by default, and those are all within the noise of overhead. I'm only talking about the function tracer that is meant to do a lot of tracing. Does LTTng trace EVERY function? Now, yes, if you only select a few functions, there's no noticeable overhead. And yes then you would need to do the stop_machine anyway, and there will be a small window where the kernel text will be writable. Tracing only a small set of functions (say a few 100) is not much of an overhead, and I could see that being done on a production system. > > I agree that the racy time window is not that large and is not really a > security concern, but it's still just annoying. Annoying? how so? Again, the stop_machine part has nothing to do with DEBUG_RODATA, it is about the safest and easiest way to modify kernel text. -- Steve