Re: [PATCH v3 0/10] Uprobes v3

[Mathieu Desnoyers]

* H. Peter Anvin (hpa@xxxxxxxxx) wrote:
> 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.

Indeed. I would add that this out-of-order observation of breakpoint
modification is already expected, because other cores may be executing arbitrary
code when we add the two breakpoints (either insnA, B, or somewhere in between,
or somewhere else entirely).

Basically, we can make no assumption about the order in which the two stores
will be seen by other CPUs. But I can't imagine a debugger expecting these two
stores to be observed in order.

If we ever want to provide a _guarantee_ that starting from a certain point all
CPUs will see a set of breakpoint, then we need to issue a core serializing
instruction on all CPUs. This would determine the "quiescent state" of the CPUs,
starting from which all of them see the breakpoints.

Thanks,

Mathieu

> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 

-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/