From: Ingo Molnar <mingo@elte•hu>
To: Linus Torvalds <torvalds@linux-foundation•org>Li
Cc: "Frank Ch. Eigler" <fche@redhat•com>,
Andrew Morton <akpm@linux-foundation•org>,
Stephen Rothwell <sfr@canb•auug.org.au>,
Ananth N Mavinakayanahalli <ananth@in•ibm.com>,
Peter Zijlstra <a.p.zijlstra@chello•nl>,
Peter Zijlstra <peterz@infradead•org>,
Fr??d??ric Weisbecker <fweisbec@gmail•com>,
LKML <linux-kernel@vger•kernel.org>,
Steven Rostedt <rostedt@goodmis•org>,
Arnaldo Carvalho de Melo <acme@redhat•com>,
linux-next@vger•kernel.org, "H. Peter Anvin" <hpa@zytor•com>,
utrace-devel@redhat•com, Thomas Gleixner <tglx@linutronix•de>
Subject: Re: linux-next: add utrace tree
Date: Sat, 23 Jan 2010 07:04:01 +0100 [thread overview]
Message-ID: <20100123060401.GB19399@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1001211826060.13231@localhost.localdomain>
* Linus Torvalds <torvalds@linux-foundation•org> wrote:
> On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
>
> > Less passionate analysis would identify a long history of contribution by
> > the the greater affiliated team, including via merged code and by and
> > passing on requirements and experiences.
>
> The reason I'm so passionate is that I dislike the turn the discussion was
> taking, as if "utrace" was somehow _good_ because it allowed various other
> interfaces to hide behind it. And I'm not at all convinced that is true.
>
> And I really didn't want to single out system tap, I very much feel the same
> way abotu some seccomp-replacement "security model that the kernel doesn't
> even need to know about" thing.
>
> So don't take the systemtap part to be the important part, it's the bigger
> issue of "I'd much rather have explicit interfaces than have generic hooks
> that people can then use in any random way".
>
> I realize that my argument is very anti-thetical to the normal CS teaching
> of "general-purpose is good". I often feel that very specific code with very
> clearly defined (and limited) applicability is a good thing - I'd rather
> have just a very specific ptrace layer that does nothing but ptrace, than a
> "generic plugin layer that can be layered under ptrace and other things".
( I think to a certain degree it mirrors the STEAMS hooks situation from a
decade ago - and while there were big flamewars back then we never regretted
not taking the STREAMS opaque hooks upstream. )
> In one case, you know exactly what the users are, and what the semantics are
> going to be. In the other, you don't.
>
> So I really want to see a very big and immediate upside from utrace. Because
> to me, the "it's a generic layer with any application you want to throw at
> it" is a _downside_.
One component of the whole utrace/systemtap codebase that i think would make
sense upstreaming in the near term is the concept of user-space probes. We are
actively looking into it from a 'perf probe' angle, and PeterZ suggested a few
ideas already. Allowing apps to transparently improve the standard set of
events is a plus. (From a pure Linux point of view it's probably more
important than any kernel-only instrumentation.)
Also, if any systemtap person is interested in helping us create a more
generic filter engine out of the current ftrace filter engine (which is really
a precursor of a safe, sandboxed in-kernel script engine), that would be
excellent as well. Right now we support simple C-syntax expressions like:
perf record -R -f -e irq:irq_handler_entry --filter 'irq==18 || irq==19'
More could be done - a simple C-like set of function perhaps - some minimal
per probe local variable state, etc. (perhaps even looping as well, with a
limit on number of predicament executions per filter invocation.)
( _Such_ a facility, could then perhaps be used to allow applications access
to safe syscall sandboxing techniques: i.e. a programmable seccomp concept
in essence, controlled via ASCII space filter expressions [broken down into
predicaments for fast execution], syscall driven and inherited by child
tasks so that security restrictions percolate down automatically.
IMHO that would be a superior concept for security modules too: there's no
reason why all the current somewhat opaque security hooks couldnt be
expressed in terms of more generic filter expressions, via a facility that
can be used both for security and for instrumentation. That's all what
SELinux boils down to in the end: user-space injected policy rules. )
The opaque hookery all around the core kernel just to push everything outside
of mainline is one of the biggest downsides of utrace/systemtap - and neither
uprobes nor the concept of user-defined scripting around existing events is
affected much by that.
So lots of work is left and all that work is going to be rather utilitarian
with little downside: specific functionality with an immediately visible
upside, with no need for opaque hooks.
Ingo
next prev parent reply other threads:[~2010-01-23 6:04 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100119211646.GF16096@redhat.com>
2010-01-20 0:12 ` linux-next: add utrace tree Stephen Rothwell
2010-01-20 5:49 ` Ingo Molnar
2010-01-20 6:15 ` Ananth N Mavinakayanahalli
2010-01-20 6:28 ` Ingo Molnar
2010-01-20 6:40 ` Ananth N Mavinakayanahalli
2010-01-20 10:43 ` Frederic Weisbecker
2010-01-20 6:59 ` Stephen Rothwell
2010-01-20 13:24 ` Frank Ch. Eigler
2010-01-20 7:29 ` Ingo Molnar
2010-01-20 14:38 ` Stephen Rothwell
2010-01-21 1:22 ` Roland McGrath
2010-01-22 0:17 ` Stephen Rothwell
2010-01-22 0:30 ` Andrew Morton
2010-01-22 0:31 ` Andrew Morton
2010-01-22 0:51 ` Frank Ch. Eigler
2010-01-22 1:05 ` Andrew Morton
2010-01-22 1:25 ` Frank Ch. Eigler
2010-01-22 1:32 ` Linus Torvalds
2010-01-22 2:22 ` Frank Ch. Eigler
2010-01-22 2:35 ` Linus Torvalds
2010-01-22 20:51 ` Oleg Nesterov
2010-01-23 6:04 ` Ingo Molnar [this message]
2010-01-23 12:03 ` Frank Ch. Eigler
2010-01-24 16:36 ` Thomas Gleixner
2010-01-22 1:28 ` Linus Torvalds
2010-01-22 5:21 ` Ananth N Mavinakayanahalli
2010-01-22 13:43 ` Valdis.Kletnieks
2010-01-22 19:39 ` Oleg Nesterov
2010-01-26 13:58 ` Pavel Machek
2010-01-22 18:28 ` Oleg Nesterov
2010-01-22 20:01 ` Frank Ch. Eigler
2010-01-22 20:16 ` Peter Zijlstra
2010-01-22 21:44 ` Frank Ch. Eigler
2010-01-22 21:59 ` Linus Torvalds
2010-01-22 22:13 ` Frank Ch. Eigler
2010-01-23 0:11 ` Linus Torvalds
2010-01-23 0:22 ` Linus Torvalds
2010-01-23 6:20 ` Kyle Moffett
2010-01-23 11:01 ` Alan Cox
2010-01-23 11:51 ` Frank Ch. Eigler
2010-01-23 15:57 ` Arnaldo Carvalho de Melo
2010-01-23 11:23 ` Ingo Molnar
2010-01-23 11:47 ` Frank Ch. Eigler
2010-01-23 19:48 ` tytso
2010-01-24 18:01 ` Frank Ch. Eigler
2010-01-25 1:42 ` Kyle Moffett
2010-01-25 4:55 ` tytso
2010-01-25 16:52 ` Linus Torvalds
2010-01-25 17:02 ` Frank Ch. Eigler
2010-01-25 17:36 ` Linus Torvalds
2010-01-25 17:45 ` Linus Torvalds
2010-01-25 17:54 ` Steven Rostedt
2010-01-25 18:03 ` Alan Cox
2010-01-25 18:12 ` Linus Torvalds
2010-01-25 18:30 ` Steven Rostedt
2010-01-25 18:45 ` Thomas Gleixner
2010-01-25 20:34 ` Ingo Molnar
2010-01-25 20:30 ` Mark Wielaard
2010-01-25 20:42 ` Linus Torvalds
2010-01-26 0:02 ` Renzo Davoli
2010-01-26 0:07 ` Linus Torvalds
2010-01-26 16:08 ` Johannes Stezenbach
2010-01-26 16:28 ` Linus Torvalds
2010-01-26 16:34 ` Christoph Hellwig
2010-01-28 23:53 ` Benjamin Herrenschmidt
2010-01-29 0:21 ` Linus Torvalds
2010-01-25 4:59 ` Ananth N Mavinakayanahalli
2010-01-25 10:13 ` Peter Zijlstra
2010-01-24 5:04 ` Linus Torvalds
2010-01-24 10:25 ` tytso
2010-01-24 13:20 ` Frank Ch. Eigler
2010-01-25 21:05 ` Tom Tromey
2010-01-25 21:41 ` Linus Torvalds
2010-01-26 14:21 ` Ananth N Mavinakayanahalli
2010-01-26 23:20 ` Tom Tromey
2010-01-26 23:37 ` Linus Torvalds
2010-01-27 6:52 ` Peter Zijlstra
2010-01-27 8:54 ` Ingo Molnar
2010-01-28 1:52 ` Jim Keniston
2010-01-28 8:55 ` Ingo Molnar
2010-01-29 0:59 ` Jim Keniston
2010-01-29 7:39 ` Ingo Molnar
2010-01-29 7:52 ` Ananth N Mavinakayanahalli
2010-01-29 7:55 ` Ananth N Mavinakayanahalli
2010-01-29 9:16 ` Ingo Molnar
2010-01-29 9:11 ` Ingo Molnar
2010-01-29 9:31 ` Ananth N Mavinakayanahalli
2010-01-29 9:51 ` Ingo Molnar
2010-01-29 18:13 ` Frank Ch. Eigler
2010-01-29 4:55 ` Ananth N Mavinakayanahalli
2010-01-29 7:42 ` Ingo Molnar
2010-01-30 17:49 ` Steven Rostedt
2010-01-30 17:59 ` Linus Torvalds
2010-02-02 6:47 ` Masami Hiramatsu
2010-01-27 10:43 ` Linus Torvalds
2010-01-27 10:55 ` Peter Zijlstra
2010-01-27 10:58 ` Peter Zijlstra
2010-01-27 11:04 ` Linus Torvalds
2010-01-27 16:01 ` Frederic Weisbecker
2010-01-27 11:05 ` Ananth N Mavinakayanahalli
2010-01-27 11:08 ` Peter Zijlstra
2010-01-27 11:20 ` Ananth N Mavinakayanahalli
2010-02-08 10:09 ` Avi Kivity
2010-01-27 11:07 ` Srikar Dronamraju
2010-01-27 13:59 ` Steven Rostedt
2010-01-27 17:42 ` H. Peter Anvin
2010-01-27 18:53 ` Steven Rostedt
2010-02-08 6:54 ` Pavel Machek
2010-02-08 9:30 ` H. Peter Anvin
2010-02-08 9:53 ` Arjan van de Ven
2010-01-27 19:18 ` H. Peter Anvin
2010-01-27 0:38 ` Frank Ch. Eigler
2010-01-26 15:00 ` Frank Ch. Eigler
2010-01-26 17:33 ` Andi Kleen
2010-01-26 18:46 ` Linus Torvalds
2010-01-26 21:02 ` Andi Kleen
2010-01-26 21:53 ` Oleg Nesterov
2010-01-26 22:03 ` Andi Kleen
2010-01-26 23:32 ` Oleg Nesterov
2010-01-26 21:30 ` Oleg Nesterov
2010-01-26 23:27 ` Tom Tromey
2010-01-23 8:05 ` Alexey Dobriyan
2010-01-22 17:45 ` Oleg Nesterov
2010-01-20 8:52 ` Peter Zijlstra
2010-01-20 13:01 ` Frank Ch. Eigler
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=20100123060401.GB19399@elte.hu \
--to=mingo@elte$(echo .)hu \
--cc=a.p.zijlstra@chello$(echo .)nl \
--cc=acme@redhat$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=ananth@in$(echo .)ibm.com \
--cc=fche@redhat$(echo .)com \
--cc=fweisbec@gmail$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=peterz@infradead$(echo .)org \
--cc=rostedt@goodmis$(echo .)org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tglx@linutronix$(echo .)de \
--cc=torvalds@linux-foundation$(echo .)org \
--cc=utrace-devel@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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