On Wed, 2010-01-27 at 07:53 +0100, Peter Zijlstra wrote:
On Fri, 2010-01-22 at 12:54 +0530, Ananth N Mavinakayanahalli wrote:
On Fri, Jan 22, 2010 at 12:32:32PM +0530, Srikar Dronamraju wrote:
Here is a summary of the Comments and actions that need to be taken for
the current uprobes
On Wed, 2010-01-27 at 02:43 -0800, Linus Torvalds wrote:
On Wed, 27 Jan 2010, Peter Zijlstra wrote:
Right, so you're going to love uprobes, which does exactly that. The
current proposal is overwriting the target instruction with an INT3 and
injecting an extra vma into the target
On Wed, 2010-01-27 at 11:55 +0100, Peter Zijlstra wrote:
Right, so there's two aspects:
1) concurrency when inserting the probe
2) concurrency when hitting the probe
1) used to be dealt with by using utrace to stop all threads in the
process and then writing the instruction. I suggested
On Wed, 2010-01-27 at 16:35 +0530, Ananth N Mavinakayanahalli wrote:
Probing RIP-relative instructions work just fine; there are fixups that
take care of it.
Ah my bad then, it was my understanding you simply bailed on those.
Just for my information, how large are the replacement sequences?
On Fri, 2010-01-22 at 12:54 +0530, Ananth N Mavinakayanahalli wrote:
On Fri, Jan 22, 2010 at 12:32:32PM +0530, Srikar Dronamraju wrote:
Here is a summary of the Comments and actions that need to be taken for
the current uprobes patchset. Please let me know if I missed or
misunderstood any
On Fri, 2010-01-22 at 15:01 -0500, Frank Ch. Eigler wrote:
So then there's uprobes, which is another potential utrace killer
app
That's bollocks, uprobes is an utter and total mis-match for utrace.
Probing userspace is primarily about DSOs which is files and vma's, not
tasks.
You might maybe
On Wed, 2010-01-20 at 11:43 +0200, Avi Kivity wrote:
1. Write a trace entry into shared memory, trap into the kernel on overflow.
2. Trap if a condition is satisfied (fast watchpoint implementation).
So now you want to consume more of a process' address space to store
trace data as well? Not to
On Mon, 2010-01-18 at 13:01 +0200, Avi Kivity wrote:
You've made it clear that you don't like it, but not why.
The kernel already manages the user's address space (except for
MAP_FIXED which is unreliable unless you've already reserved the address
space). I don't see why adding a vma
On Mon, 2010-01-18 at 13:01 +0200, Avi Kivity wrote:
If we reserve some address space, you don't add any heisenbugs (at
least, not any additional ones over emulation). Even if we don't,
address space layout randomization means we're not keeping the address
space layout constant between
On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote:
Maybe you place no value on uprobes. But people who debug userspace
likely will see a reason.
I do see value in uprobes, I just don't like it mucking about with the
address space. Nor does it appear required.
On Mon, 2010-01-18 at 14:17 +0200, Avi Kivity wrote:
On 01/18/2010 02:13 PM, Pekka Enberg wrote:
So how big chunks of the address space are we talking here for uprobes?
That's for the authors to answer, but at a guess, 32 bytes per probe
(largest x86 instruction is 15 bytes), so 32
On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote:
On 01/18/2010 02:14 PM, Peter Zijlstra wrote:
Well, the alternatives are very unappealing. Emulation and
single-stepping are going to be very slow compared to a couple of jumps.
With CPL2 or RPL on user segments the protection
On Sun, 2010-01-17 at 16:56 +0200, Avi Kivity wrote:
On 01/17/2010 04:52 PM, Peter Zijlstra wrote:
Also, if its fixed size you're imposing artificial limits on the number
of possible probes.
Obviously we'll need a limit, a uprobe will also take kernel memory, we
can't allow people
On Sun, 2010-01-17 at 16:59 +0200, Avi Kivity wrote:
On 01/17/2010 04:52 PM, Peter Zijlstra wrote:
On Sun, 2010-01-17 at 16:39 +0200, Avi Kivity wrote:
On 01/15/2010 11:50 AM, Peter Zijlstra wrote:
As previously stated, I think poking at a process's address space is an
utter
On Sat, 2010-01-16 at 18:48 -0500, Jim Keniston wrote:
As you may have noted before, I think FP would be a special problem
for your approach. I'm not sure how folks would react to the idea of
executing FP instructions in kernel space. But emulating them is also
tough. There's an IEEE
On Sat, 2010-01-16 at 19:12 -0500, Bryan Donlan wrote:
On Fri, Jan 15, 2010 at 7:58 PM, Jim Keniston jkeni...@us.ibm.com wrote:
4. Emulation removes the need for the XOL area, but requires pretty much
total knowledge of the instruction set. It's also a performance win for
architectures
On Sun, 2010-01-17 at 21:33 +0200, Avi Kivity wrote:
On 01/17/2010 05:03 PM, Peter Zijlstra wrote:
btw, an alternative is to require the caller to provide the address
space for this. If the caller is in another process, we need to allow
it to play with the target's address space (i.e
On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
discussed elsewhere.
Thanks for the pointer...
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
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
On Fri, 2010-01-15 at 15:08 +0530, Ananth N Mavinakayanahalli wrote:
On Fri, Jan 15, 2010 at 10:03:48AM +0100, Peter Zijlstra wrote:
On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
discussed elsewhere.
Thanks for the pointer...
:-)
Peter,
I think Jim was referring
On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:
Ideas?
emulate the one instruction?
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, 2010-01-15 at 15:52 +0530, Ananth N Mavinakayanahalli wrote:
On Fri, Jan 15, 2010 at 11:13:32AM +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:
Ideas?
emulate the one instruction?
In kernel? Generically? Don't think its
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
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
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 13:07 -0800, Jim Keniston wrote:
On Fri, 2010-01-15 at 10:02 +0100, Peter Zijlstra wrote:
On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
+Instruction copies to be single-stepped are stored in a per-process
+single-step out of line (XOL) area, which
On Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote:
User Space Breakpoint Assistance Layer (UBP)
User space breakpointing Infrastructure provides kernel subsystems
with architecture independent interface to establish breakpoints in
user applications. This patch provides core
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 Mon, 2010-01-11 at 17:55 +0530, Srikar Dronamraju wrote:
Execution out of line (XOL)
Slot allocation mechanism for Execution Out of Line strategy in User
space breakpointing Inftrastructure. (XOL)
This patch provides slot allocation mechanism for execution out of
line strategy for use
On Thu, 2010-01-14 at 12:23 +0100, Peter Zijlstra wrote:
On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote:
This patch implements ftrace plugin for uprobes.
Right, like others have said, trace events is a much saner interface.
So the easiest way I can see that working
On Thu, 2010-01-14 at 12:35 +0100, Frederic Weisbecker wrote:
On Thu, Jan 14, 2010 at 12:23:11PM +0100, Peter Zijlstra wrote:
On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote:
This patch implements ftrace plugin for uprobes.
Right, like others have said, trace events is a much
On Thu, 2010-01-14 at 13:16 +0100, Mark Wielaard wrote:
On Thu, 2010-01-14 at 12:29 +0100, Peter Zijlstra wrote:
On Thu, 2010-01-14 at 12:23 +0100, Peter Zijlstra wrote:
On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote:
This patch implements ftrace plugin for uprobes
On Sun, 2009-12-13 at 16:25 -0800, Roland McGrath wrote:
I'm sorry for the delay. I'm picking up with responding to the parts of
your review that I did not include in my first reply. I appreciate very
much the discussion you've had with Oleg about the issues that I did not
address myself. I
On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
The
problem is, this code was developed out-of-tree. That is why we would
like to merge it asap, then do other changes which could be easily
reviewed.
Now, do you really mean we should throw out the working code, rewrite
it avoiding
On Tue, 2009-12-08 at 17:31 +0100, Oleg Nesterov wrote:
If you take a task ref you can write the much saner:
utrace_control()
{
...
spin_lock(utrace-lock);
...
if (reset)
utrace_reset(utrace);
spin_unlock(utrace-lock);
}
No, get_task_struct() in
On Tue, 2009-12-01 at 23:08 +0100, Oleg Nesterov wrote:
@@ -560,6 +625,20 @@ static inline void tracehook_report_deat
int signal, void *death_cookie,
int group_dead)
{
+ /*
+ * This barrier ensures that
On Tue, 2009-11-24 at 21:02 +0100, Oleg Nesterov wrote:
+ sect2 id=reaptitleFinal callbacks/title
+ para
+The functionreport_reap/function callback is always the final event
+in the life cycle of a traced thread. Tracing engines can use this as
+the trigger to clean up their
On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote:
This patch implements an in-kernel gdb stub.
It provides an interface between gdb and Linux Kernel by implementing
the remote serial protocol. This gdbstub uses utrace infrastructure.
This patch provides register set access, signal
On Mon, 2009-11-30 at 18:02 +0530, Srikar Dronamraju wrote:
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:09:12]:
On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote:
This patch implements an in-kernel gdb stub.
It provides an interface between gdb and Linux Kernel
On Mon, 2009-11-30 at 18:49 +0530, Srikar Dronamraju wrote:
This is suppose to be one of the interfaces to use utrace, i.e Allow
gdb to use utrace features without having to change gdb itself.
Though there are not enough features in this patch, intentions include
support multi-threaded
On Thu, 2009-11-26 at 12:37 +0530, Srikar Dronamraju wrote:
Hi Christoph,
The other thing is that this patchset really doesn't quite justify
utrace. It's growing a lot more code without actually growing any
useful functionality. What about all those other utrace killer
features
45 matches
Mail list logo
