On Thu, 2010-01-14 at 14:49 -0800, Jim Keniston wrote:
On Thu, 2010-01-14 at 12:09 +0100, Peter Zijlstra wrote:
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote:
Uprobes Infrastructure enables user to dynamically establish
probepoints in user applications and collect
Peter Zijlstra pet...@infradead.org writes:
[...]
Right, so all that need be done is add the multiple probe stuff to UBP
and its a sane interface to use on its own, at which point I'd be
inclined to call that uprobes (UBP really is an crap name).
At one point ubp+uprobes were one piece.
On Fri, 2010-01-15 at 04:26 -0500, Frank Ch. Eigler wrote:
Peter Zijlstra pet...@infradead.org writes:
[...]
Right, so all that need be done is add the multiple probe stuff to UBP
and its a sane interface to use on its own, at which point I'd be
inclined to call that uprobes (UBP really
Hi Peter,
My reply in
http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02483.html
addresses this.
Right, so all that need be done is add the multiple probe stuff to UBP
and its a sane interface to use on its own, at which point I'd be
inclined to call that uprobes (UBP
On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
Hi Peter,
Or there could be two threads that could be racing to
insert/delete a breakpoint. These synchronization issues are all handled
by the Uprobes layer.
Shouldn't be hard to put that in the ubp layer, right?
Uprobes layer
On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
Hi Peter,
Or there could be two threads that could be racing to
insert/delete a breakpoint. These synchronization issues are all handled
by the Uprobes layer.
On Fri, 2010-01-15 at 16:35 +0530, Maneesh Soni wrote:
On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
Hi Peter,
Or there could be two threads that could be racing to
insert/delete a breakpoint. These
On Fri, 2010-01-15 at 12:12 +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 16:35 +0530, Maneesh Soni wrote:
On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
Hi Peter,
Or there could be two threads
* Peter Zijlstra pet...@infradead.org [2010-01-15 11:33:27]:
Uprobes layer would need to be notified of process life-time events
like fork/clone/exec/exit.
No so much the process lifetimes as the vma life times are interesting,
placing a hook in the vm code to track that isn't too
Hi -
Then we can ditch the whole utrace muck as I see no reason to want to
use that, whereas the ubp (given a sane name) looks interesting.
Assuming you meant what you write, perhaps you misunderstand the
layering relationship of these pieces. utrace underlies uprobes and
other
On Fri, 2010-01-15 at 19:50 +0530, Srikar Dronamraju wrote:
Srikar seemed to suggest it needed stop/resume.
If process traps, We dont need to stop/resume other threads.
uprobes needs threads to quiesce when inserting/deleting the breakpoint.
Right, I don't think we need to at all. See
On Fri, 2010-01-15 at 09:22 -0500, Frank Ch. Eigler wrote:
Hi -
Well, I'm not in a position to argue line by line about the necessity
or the cost of utrace low level guts, but this may represent the most
practical engineering balance between functionality / modularity /
undesirably
On Fri, 2010-01-15 at 12:18 +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 12:12 +0100, Peter Zijlstra wrote:
...
Adding the probe uses the fact that (most) executable mappings are
MAP_PRIVATE and CoWs a private copy of the page with the modified ins,
right?
We've just used
On Fri, 2010-01-15 at 19:50 +0530, Srikar Dronamraju wrote:
Furthermore it requires stopping and resuming tasks and nonsense like
that, that's unwanted in many cases, just run stuff from the trap site
and you're done.
I don't know what you mean exactly. A trap already
On Fri, 2010-01-15 at 12:12 +0100, Peter Zijlstra wrote:
...
Adding the probe uses the fact that (most) executable mappings are
MAP_PRIVATE and CoWs a private copy of the page with the modified ins,
right?
What does it do for MAP_SHARED|MAP_EXECUTABLE sections -- simply fail to
add the
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote:
Uprobes Infrastructure enables user to dynamically establish
probepoints in user applications and collect information by executing
a handler functions when the probepoints are hit.
Please refer Documentation/uprobes.txt for more
On Tue, 2010-01-12 at 13:44 +0530, Ananth N Mavinakayanahalli wrote:
Well, I wonder if perf can ride on utrace's callbacks for the
hook_task() for the clone/fork cases?
Well it could, but using all of utrace to simply get simple callbacks
from copy_process() is just daft so we're not going
On Thu, 2010-01-14 at 12:09 +0100, Peter Zijlstra wrote:
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote:
Uprobes Infrastructure enables user to dynamically establish
probepoints in user applications and collect information by executing
a handler functions when the
On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote:
On Mon, Jan 11, 2010 at 05:55:53PM +0530, Srikar Dronamraju wrote:
+static const struct utrace_engine_ops uprobe_utrace_ops = {
+ .report_quiesce = uprobe_report_quiesce,
+ .report_signal = uprobe_report_signal,
+
On Tue, 2010-01-12 at 13:44 +0530, Ananth N Mavinakayanahalli wrote:
On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote:
...
So, as stated before, uprobe seems to handle too much standalone
policies such as freeing on exec, always inherit on clone and never
on fork. Such
20 matches
Mail list logo
