linux-kernel - Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090321050422.d1d99eec.akpm@linux-foundation.org>
Date:	Sat, 21 Mar 2009 05:04:22 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Roland McGrath <roland@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>, utrace-devel@...hat.com,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2

On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@...hat.com> wrote:

> Hi -
> 
> On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > [...]
> > > Utrace is very much tracing material - without the ftrace plugin the 
> > > whole utrace machinery is just something that provides a _ton_ of 
> > > hooks to something entirely external: SystemTap mainly.
> > 
> > Roland's changelogs don't mention systemtap at all afacit.
> > That was, umm, major information lossage.
> 
> There have been many mixed messages from LKML on the topic - sometimes
> mentioning systemtap is forbidden, other times necessary.  Sorry about
> that.

heh.  We all love systemtap and want it to get better.

> There are several non-systemtap clients in existence or under
> development.  You've may have heard of the ptrace cleanup, a
> multi-client ptrace replacement, an on-the-fly core dumper, the ftrace
> widget, user-space probes.  All of these should have somewhat
> compelling non-systemtap uses, if that's an important criterion.

Well I dunno.  You guys are closer to this than I am, but I'd have thought
that systemtap is the main game here, and most/all of the above is just
fluff.

IOW, "this helps systemtap" is sufficient reason for merging a kernel
change.  For sufficiently large values of "help", and sufficiently small
values of "eww", of course.



I have strong memories of being traumatised by reading the uprobes code. 
What's the story on all of that nowadays?


> 
> > Actually it seems that the whole utrace-ftrace thing is a big
> > distraction and could/should just be omitted.  This is a systemtap
> > feature and should be viewed as such. [...]
> 
> utrace is a better way to perform user thread management than what is
> there now, and the utrace-ftrace widget shows how to *hook* thread
> events such as syscalls in a lighter weight / more managed way than
> the first one proposed.  (That's one reason we've been participating
> in the ftrace discussions.)  Of course it can be made to use the fine
> syscall pretty-printing code recently added.

eh.  Boring.  Let's fix systemtap?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/