This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hitachi djprobe mechanism


* Andi Kleen (ak@suse.de) wrote:
> Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> > 
> > And as the jmp instruction is 5 bytes, there seems to be no hope to find an
> > atomic operation that will write that.
> 
> Any 64bit architecture can write 8 bytes mostly atomically (at least towards
> readers) and many 32bit architectures (like newer x86 with cmpxchg or sse) 
> can too.
> 
> An 8 byte read-modify-store is not protected against multiple writers,
> but that is no problem for probes which can protect against that
> with a different lock.
> 
> x86 could actually do it atomically even for writers with cmpxchg8.
> 
> -Andi
> 

It's probably a small bit of understanding of cmpxch I am missing here, but what
would happen if :

CPU A                                 CPU B
read first byte of jmp instruction

                                      lock; cmpxch of the 2 bytes of the jmp
                                      instruction.
                                      
read the second byte of jmp
instruction

As I see it, the write in memory is atomic, but not the instruction fetching. In
that case, the reader would see an inconsistent last jmp address byte.

cmpxch seems ok if the reader does read the 64 bits more than once to check if
it has changed behind it. Or is there a special lock prefix to a 64 bits read
operation I am not aware of ? (on 32 bits arch)


Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]