Re: [PATCH v3 0/10] Uprobes v3

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

* Ananth N Mavinakayanahalli (ananth@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