linux-kernel - Re: [PATCH v1 7/10] Uprobes Implementation

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:	Wed, 24 Mar 2010 11:29:39 +0530
From:	Ananth N Mavinakayanahalli <ananth@...ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mel Gorman <mel@....ul.ie>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v1 7/10] Uprobes Implementation

On Tue, Mar 23, 2010 at 04:15:54PM +0100, Peter Zijlstra wrote:
> On Tue, 2010-03-23 at 20:35 +0530, Ananth N Mavinakayanahalli wrote:
> > Now the question is, where the complexity needs to be.
> 
> Both in-tree consumers of uprobes (ftrace and perf) are capable of task
> filters.
> 
> But the thing is, dso:sym is very much not a task property, adding task
> filters afterwards sure makes sense in some cases but it should not be
> the primary mode.

Not sure if I am following you correctly...

> If people really want to optimize this we can easily add a few bits of
> task state which could tell the trap handler to not even bother looking
> up things but restart as fast as possible.

Are you suggesting we have the global tracing as default and
then have task filters. I've already alluded to this being vetoed
earlier, by people including Andrew Morton, Hugh Dickins, Arjan,
Christoph Hellwig, Nick Piggin, etc. It's a route we'd prefer not to
go down again...

Aside, what are the mechanisms to do this?

The current breakpoint insertion and removal, even for shared libraries,
is process local since the only page tables of the process being traced
is modified.

In order to have a global visibility of dso probes, one obvious method
is to put in the probes before the text hits pagecache. This approach
works for 'yet-to-start' processes that would map the dso too. This was
prototyped in the series at http://lkml.org/lkml/2006/5/9/25 did that
and was suitably junked, for very valid reasons. Even Hugh Dickins
thumbed down the pagecache approach (http://lkml.org/lkml/2006/5/9/209)

Given the current design has enough flexibility to accommodate non perf
users like gdb, a simple pid based approach for the lowest layer makes
the most sense. I'd rather prefer a higher level entity (say, perf) do
the difficult job of filtering down individual requests only for
processes of interest, then the lower layer can iteratively do the probe
insertions for all processes of interest.

I am not sure if there is a better method to do probes with 'global'
visibility. Did you have an easier approach in mind?

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