This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: Richard J Moore <richardj_moore at uk dot ibm dot com>
- Cc: Andi Kleen <ak at suse dot de>, Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Karim Yaghmour <karim at opersys dot com>, Masami Hiramatsu <masami dot hiramatsu at gmail dot com>, michel dot dagenais at polymtl dot ca, Roland McGrath <roland at redhat dot com>, Satoshi Oshima <soshima at redhat dot com>, sugita at sdl dot hitachi dot co dot jp, systemtap at sources dot redhat dot com
- Date: Mon, 1 Aug 2005 09:09:29 -0400
- Subject: Re: Hitachi djprobe mechanism
- References: <20050731220304.GJ3726@bragg.suse.de> <OF331D042E.CCADD212-ON41257050.002DC63A-41257050.002F8168@uk.ibm.com>
* Richard J Moore (richardj_moore@uk.ibm.com) wrote:
>
> Intel erratum 54 - Unsynchronized Cross-modifying code - refers to the
> practice of modifying code on one processor where another has prefetched
> the unmodified version of the code. Intel states that unpredictable general
> protection faults may result if a synchronizing instruction (iret, int,
> int3, cpuid, etc ) is not executed on the second processor before it
> executes the pre-fetched out-of-date copy of the instruction.
>
Well, using an IPI that would make all other CPUs loop waiting for the specific
memory address to have been written with the expected new instructions seems to
fit it this description too : they will all have to return from interrupt before
going back to the modified code path.
[...]
> So, is cmpxchg reliable? One has to guarantee more than mere atomicity.
>
Thanks for pointing that out : it gives the technical explanation of something I
only suspected.
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68