linux-kernel - Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)registration and exception handling.

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]

Date:	Mon, 6 Sep 2010 16:40:42 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 5/15]  5: uprobes: Uprobes
 (un)registration and exception handling.

On Mon, Sep 06, 2010 at 11:16:42PM +0530, Srikar Dronamraju wrote:
> > You don't have to, but you can. The problem I have with this stuff is
> > that it makes the pid thing a primary interface, whereas it should be
> > one of many filter possibilities.
> 
> I think the otherway, 
> Why instrument a process and filter it out, if we are not interested in it.
> While instrumenting kernel, we dont have this flexibility. So
> having a pid based filter is the right thing to do for kernel
> based tracing.
> 
> If we can get the per process based tracing right, we can build
> higher lever stuff including the file based tracing easily.
> 
> All tools/debuggers in the past have all worked with process based
> tracing.

I have the feeling that you guys are at least partially talking past
each other.

For the "perf probe --add" interface the only sane interface is one by
filename and then symbol / liner number / etc.

But that is just the interface - these probes don't nessecarily have to
be armed and cause global overhead once they are define.  If the
implenmentation is smart enough it will defer arming the probe until
we actually use it, and that will be per-process quite often.

Which btw, brings up two more issues, one in uprobes and one in perf.
For one even in userspace I think the dynamic probes will really just
be the tip of the iceberg and we'll get more bang for the buck from
static traces, which is something that's no supported in uprobes yet.
As a start supporting the dtrace-style sdt.h header would be a great
help, and then we can decide if we need somthing even better on top.

The other things is that perf currently only supports per-kernel pid
recording, while we'd really need per Posix process, which may contain
multiple threads for useful tracing of complex userspace applications.
I also suspect that this will fit the uprobes model much better given
that the probes will be in any given address space.

--
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/