Messages in this thread | | | Date | Fri, 11 May 2007 10:27:29 +0530 | From | Ananth N Mavinakayanahalli <> | Subject | Re: [patch 05/10] Linux Kernel Markers - i386 optimized version |
| |
On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: > * Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
... > > > * Third issue : Scalability. Changing code will stop every CPU on the > > > system for a while. Compared to this, the int3-based approach will run > > > through the breakpoint handler "if" one of the CPU happens to execute > > > this code at the wrong time. The standard case is just an IPI (to > > > > If I read the errata right then patching in an int3 will itself trigger > > the errata so anything could happen. > > > > I believe there are other safe sequences for doing code patching - perhaps > > one of the Intel folk can advise ?
IIRC, when the first implementation of what exists now as kprobes was done (as part of the dprobes framework), this question did come up. I think the conclusion was that the errata applies only to multi-byte modifications and single-byte changes are guaranteed to be atomic. Given int3 on Intel is just 1-byte, we are safe.
> I'll let the Intel guys confirm this, I don't have the reference nearby > (I got this information by talking with the kprobe team members, and > they got this information directly from Intel developers) but the > int3 is the one special case to which the errata does not apply. > Otherwise, kprobes and gdb would have a big, big issue.
Perhaps Richard/Suparna can confirm.
Ananth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |