From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
Rusty Russell <rusty@rustcorp.com.au>,
"H. Peter Anvin" <hpa@zytor.com>,
Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions
Date: Mon, 23 Feb 2009 10:55:11 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.2.00.0902231053360.18221@gandalf.stny.rr.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0902231044050.18221@gandalf.stny.rr.com>
On Mon, 23 Feb 2009, Steven Rostedt wrote:
>
> 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?
BTW, The above is more about the answer to my statement about running on
a production system. Below, is more an answer to the above. After
rereading what I wrote, I did not explain it very well.
-- Steve
>
> 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
>
>
next prev parent reply other threads:[~2009-02-23 15:55 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-20 1:13 [git pull] changes for tip, and a nasty x86 page table bug Steven Rostedt
2009-02-20 1:13 ` [PATCH 1/6] x86: check PMD in spurious_fault handler Steven Rostedt
2009-02-20 1:13 ` [PATCH 2/6] x86: keep pmd rw bit set when creating 4K level pages Steven Rostedt
2009-02-20 1:13 ` [PATCH 3/6] ftrace: allow archs to preform pre and post process for code modification Steven Rostedt
2009-02-20 1:13 ` [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions Steven Rostedt
2009-02-20 1:32 ` Andrew Morton
2009-02-20 1:44 ` Steven Rostedt
2009-02-20 2:05 ` [PATCH][git pull] update to tip/tracing/ftrace Steven Rostedt
2009-02-22 17:50 ` [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions Andi Kleen
2009-02-22 22:53 ` Steven Rostedt
2009-02-23 0:29 ` Andi Kleen
2009-02-23 2:33 ` Mathieu Desnoyers
2009-02-23 4:29 ` Steven Rostedt
2009-02-23 4:53 ` Mathieu Desnoyers
2009-02-23 14:48 ` Steven Rostedt
2009-02-23 15:42 ` Mathieu Desnoyers
2009-02-23 15:51 ` Steven Rostedt
2009-02-23 15:55 ` Steven Rostedt [this message]
2009-02-23 16:13 ` Mathieu Desnoyers
2009-02-23 16:48 ` Steven Rostedt
2009-02-23 17:31 ` Mathieu Desnoyers
2009-02-23 18:17 ` Steven Rostedt
2009-02-23 18:34 ` Mathieu Desnoyers
2009-02-27 17:52 ` Masami Hiramatsu
2009-02-27 18:07 ` Mathieu Desnoyers
2009-02-27 18:34 ` Masami Hiramatsu
2009-02-27 18:53 ` Mathieu Desnoyers
2009-02-27 20:57 ` Masami Hiramatsu
2009-03-02 17:01 ` [RFC][PATCH] x86: make text_poke() atomic Masami Hiramatsu
2009-03-02 17:19 ` Mathieu Desnoyers
2009-03-02 22:15 ` Masami Hiramatsu
2009-03-02 22:22 ` Ingo Molnar
2009-03-02 22:55 ` Masami Hiramatsu
2009-03-02 23:09 ` Ingo Molnar
2009-03-02 23:38 ` Masami Hiramatsu
2009-03-02 23:49 ` Ingo Molnar
2009-03-03 0:00 ` Mathieu Desnoyers
2009-03-03 0:00 ` [PATCH] Text Edit Lock - Architecture Independent Code Mathieu Desnoyers
2009-03-03 0:32 ` Ingo Molnar
2009-03-03 0:39 ` Mathieu Desnoyers
2009-03-03 1:30 ` [PATCH] Text Edit Lock - Architecture Independent Code (v2) Mathieu Desnoyers
2009-03-03 1:31 ` [PATCH] Text Edit Lock - kprobes architecture independent support (v2) Mathieu Desnoyers
2009-03-03 9:27 ` Ingo Molnar
2009-03-03 12:06 ` Ananth N Mavinakayanahalli
2009-03-03 14:28 ` Mathieu Desnoyers
2009-03-03 14:33 ` [PATCH] Text Edit Lock - kprobes architecture independent support (v3) Mathieu Desnoyers
2009-03-03 14:53 ` [PATCH] Text Edit Lock - kprobes architecture independent support (v2) Ingo Molnar
2009-03-03 0:01 ` [PATCH] Text Edit Lock - kprobes architecture independent support Mathieu Desnoyers
2009-03-03 0:10 ` Masami Hiramatsu
2009-03-03 0:05 ` [RFC][PATCH] x86: make text_poke() atomic Masami Hiramatsu
2009-03-03 0:22 ` Ingo Molnar
2009-03-03 0:31 ` Masami Hiramatsu
2009-03-03 16:31 ` [PATCH] x86: make text_poke() atomic using fixmap Masami Hiramatsu
2009-03-03 17:08 ` Mathieu Desnoyers
2009-03-05 10:38 ` Ingo Molnar
2009-03-06 14:06 ` Ingo Molnar
2009-03-06 14:49 ` Masami Hiramatsu
2009-03-02 18:28 ` [RFC][PATCH] x86: make text_poke() atomic Arjan van de Ven
2009-03-02 18:36 ` Mathieu Desnoyers
2009-03-02 18:55 ` Arjan van de Ven
2009-03-02 19:13 ` Masami Hiramatsu
2009-03-02 19:23 ` H. Peter Anvin
2009-03-02 19:47 ` Mathieu Desnoyers
2009-03-02 18:42 ` Linus Torvalds
2009-03-03 4:54 ` Nick Piggin
2009-02-23 18:23 ` [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions Steven Rostedt
2009-02-23 9:02 ` Ingo Molnar
2009-02-27 21:08 ` Pavel Machek
2009-02-28 16:56 ` Andi Kleen
2009-02-28 22:08 ` Pavel Machek
[not found] ` <87wsba1a9f.fsf@basil.nowhere.org>
2009-02-28 22:19 ` Pavel Machek
2009-02-28 23:52 ` Andi Kleen
2009-02-20 1:13 ` [PATCH 5/6] ftrace: immediately stop code modification if failure is detected Steven Rostedt
2009-02-20 1:13 ` [PATCH 6/6] ftrace: break out modify loop immediately on detection of error Steven Rostedt
2009-02-20 2:00 ` [git pull] changes for tip, and a nasty x86 page table bug Linus Torvalds
2009-02-20 2:08 ` Steven Rostedt
2009-02-20 3:44 ` Linus Torvalds
2009-02-20 4:00 ` Steven Rostedt
2009-02-20 4:17 ` Linus Torvalds
2009-02-20 4:34 ` Steven Rostedt
2009-02-20 5:02 ` Huang Ying
2009-02-20 7:29 ` [PATCH] x86: use the right protections for split-up pagetables Ingo Molnar
2009-02-20 7:39 ` [PATCH, v2] " Ingo Molnar
2009-02-20 8:02 ` Ingo Molnar
2009-02-20 10:24 ` Ingo Molnar
2009-02-20 13:57 ` [PATCH] " Steven Rostedt
2009-02-20 15:40 ` Linus Torvalds
2009-02-20 16:59 ` Ingo Molnar
2009-02-20 18:33 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.0902231053360.18221@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=srostedt@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).