* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
