Uprobes v3
in [Kernel]
|
Prev: BUG: amd64-agp (2.6.34-rc7)
Next: [RFC] PyTimechart
From: Srikar Dronamraju on 12 May 2010 09:50 * Frederic Weisbecker <fweisbec(a)gmail.com> [2010-05-12 12:38:35]: > On Thu, May 06, 2010 at 11:31:39PM +0530, Srikar Dronamraju wrote: > > intro.patch > > > > From: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> > > > > Uprobes Patches > > > > I can't find the trace event patch inside this set. > May be you missed it somehow? (or I did). > > Thanks. > http://lkml.org/lkml/2010/5/6/284 However there were no changes from the patchset in version 2. So your comments hold good for this version too. -- Thanks and Regards Srikar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ananth N Mavinakayanahalli on 12 May 2010 10:10 On Wed, May 12, 2010 at 03:39:20PM +0200, Peter Zijlstra wrote: > On Wed, 2010-05-12 at 18:57 +0530, Ananth N Mavinakayanahalli wrote: > > Now, as long as we have the housekeeping code to handle the > > possibility of a thread hitting the said breakpoint when its being > > removed, is it safe to assume atomicity for replacing one byte of > > possibly a longer instruction? > > Dunno I'm not a hardware guy, but the issue is so simple to side-step > I'm not sure why you're arguing for relying on these special semantics. Yes we know what to do, but I am just trying to get clarity if its possible at all, since Mathieu was pretty sure that the hoops aren't necessary... Ananth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mathieu Desnoyers on 12 May 2010 10:50 * Ananth N Mavinakayanahalli (ananth(a)in.ibm.com) wrote: > On Wed, May 12, 2010 at 03:39:20PM +0200, Peter Zijlstra wrote: > > On Wed, 2010-05-12 at 18:57 +0530, Ananth N Mavinakayanahalli wrote: > > > Now, as long as we have the housekeeping code to handle the > > > possibility of a thread hitting the said breakpoint when its being > > > removed, is it safe to assume atomicity for replacing one byte of > > > possibly a longer instruction? > > > > Dunno I'm not a hardware guy, but the issue is so simple to side-step > > I'm not sure why you're arguing for relying on these special semantics. > > Yes we know what to do, but I am just trying to get clarity if its > possible at all, since Mathieu was pretty sure that the hoops aren't > necessary... From what I gathered in the Intel code modification documentation, setting a breakpoint instruction is both atomic and OK with respect to concurrent CPUs executing the code. The breakpoint instruction itself deals with serialization of remote cores when it is hit. Placing back _the original instruction_ is considered as safe too, as it is both atomic and brings back the remote cores to the original code state. Basically, these cores either observe the int3, or the original code. If they observe the int3, they perform core serialization. If they observe the original code, they either have never observed the int3 version (which is fine, it is as if the code had never changed), or if they did observe the int3, they executed the serialization instruction at the int3, so it's OK to put back the original instruction. Now the tricky case is the sequence: instruction A -> int3 -> instruction B, because a core can only see "instruction A -> instruction B" without any core synchronization whatsoever, and may not see the int3. That's where the djprobes logic (with IPIs to all cores) comes into play. But as long as we stick to "insn A -> int3 -> insn A", things can be done very simply. By the way, kprobes rely on the assumption that it is OK to put a breakpoint atomically and to put back the original instruction afterward. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 12 May 2010 11:00 On Wed, May 12, 2010 at 07:09:52PM +0530, Srikar Dronamraju wrote: > * Frederic Weisbecker <fweisbec(a)gmail.com> [2010-05-12 12:38:35]: > > > On Thu, May 06, 2010 at 11:31:39PM +0530, Srikar Dronamraju wrote: > > > intro.patch > > > > > > From: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> > > > > > > Uprobes Patches > > > > > > > > I can't find the trace event patch inside this set. > > May be you missed it somehow? (or I did). > > > > Thanks. > > > > http://lkml.org/lkml/2010/5/6/284 I missed it somehow. Nevermind. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 12 May 2010 13:10
On 05/12/2010 07:46 AM, Mathieu Desnoyers wrote: > > Now the tricky case is the sequence: instruction A -> int3 -> instruction B, > because a core can only see "instruction A -> instruction B" without any > core synchronization whatsoever, and may not see the int3. That's where the > djprobes logic (with IPIs to all cores) comes into play. But as long as we stick > to "insn A -> int3 -> insn A", things can be done very simply. > > By the way, kprobes rely on the assumption that it is OK to put a breakpoint > atomically and to put back the original instruction afterward. > Keep in mind the following corner case, though: insnA -> int3@A -> insnA insnB -> int3@B -> insnB It is now possible for the core to hit int3@A, without the int3@B being there. The int3 handler *has* to be able to handle any of the int3's put in place, quite possibly out of order, until a core serialization is performed. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |