Re: linux-next: add utrace tree

Srikar Dronamraju
2010-01-27T11:07:35Z

* Linus Torvalds <torvalds@linux-foundation.org> [2010-01-27 02:43:39]:

>
>
> 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 process's address space
> > containing the original instruction(s) and possible jumps back to the
> > old code stream.
>
> Just out of interest, how does it handle the threading issue?

I am not sure why threading would be an issue with XOL. Since all
threads of a process would have access to the XOL VMA.
i.e This XOL VMA is a per-process VMA that gets attached to the process address space
only when we hit the first breakpoint.
We reserve a slot for each breakpoint in the XOL VMA, whenever the trap
is hit, we jump to the corresponding slot, single step and jump back
after necessary fix-ups.
We have been able to use this approach in multithreaded applications.
However if you see any issues, can you please let us know?

>
> Last I saw, at least some CPU people were _very_ nervous about overwriting
> instructions if another CPU might be just about to execute them.
>
> Even the "overwrite only the first byte with 'int3'" made them go "umm, I
> need to talk to some core CPU people to see if that's ok". They mumble
> about possible CPU errata, I$ coherency, instruction retry etc.

Thats exactly why we waited for threads to queisce before inserting and
deleting the breakpoints. However we were advised by lkml that there are
better ways to insert/delete breakpoints without quiescing by adjusting
the page table entries similar to what you said just below. And we are
working on switching the page table entry solution.

>
> I realize kprobes does this very thing, but kprobes is esoteric stuff and
> doesn't have much choice. In user space, you _could_ do the modification
> on a different physical page and then just switch the page table entry
> instead, and not get into the whole D$/I$ coherency thing at all.
>
> Linus
>

--
Thanks and Regards
Srikar