This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [patch 05/10] Linux Kernel Markers - i386 optimized version
- From: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: Alan Cox <alan at lxorguk dot ukuu dot org dot uk>, Andi Kleen <ak at muc dot de>, systemtap at sources dot redhat dot com, prasanna at in dot ibm dot com, anil dot s dot keshavamurthy at intel dot com, akpm at linux-foundation dot org, linux-kernel at vger dot kernel dot org, hch at infradead dot org, richardj_moore at uk dot ibm dot com, suparna at in dot ibm dot com
- Date: Fri, 11 May 2007 10:27:29 +0530
- Subject: Re: [patch 05/10] Linux Kernel Markers - i386 optimized version
- References: <20070510015555.973107048@polymtl.ca> <20070510020916.508519573@polymtl.ca> <20070510090656.GA57297@muc.de> <20070510155501.GI22424@Krystal> <20070510172843.7aa72237@the-village.bc.nu> <20070510165918.GK22424@Krystal>
- Reply-to: ananth at in dot ibm dot com
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