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:
> > 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.
> 
> Yes, you're right. cmpxchg only helps when the replaced instruction
> is >= the new instruction. For smaller instructions only a IPI to
> stop all CPUs works.
> 

It was not exactly the point of my comment. If we try to overwrite an existing
instruction, without any marker, two cases may show up :

* the instruction to replace is >= the jmp instruction (5 bytes)

It has been suggested that using cmpxchg8 would solve this problem. cmpxchg8
does indeed commit 8 bytes of data to memory atomically, even on 32 bits
architectures.

My question is related to the instruction we want to replace : how is it read by
the CPU ? If it's 5 bytes in size, il has to be read in two chunks by the cpu in
a 32 bits arch. Does the CPU lock the memory bus between those two read ?

If not, we still have a problem : the second read might be inconsistent with the
first one, even of the cmpxchg8 has been done atomically.


* the instruction to replace is < the jmp instruction (4 bytes or less)

If our goal is to overwrite code which has not been surrounded by a marker, an
IPI wouldn't save us here. The marker is necessary in order to disable
interruptions and make the IPI meaningful.


> Actually there may be tricks possible to first int3 (or equivalent single
> byte replacement on other archs) the second instruction,
> then the first, then wait for a RCU period of all CPUs to quiescence and then
> write the longer jump. But an IPI is probably easier because it doesn't need 
> a full disassembler for this and setting probes should not be performance
> critical.
>

Well, in fact, there is still a problem. (on no, not again!) ;)  The RCU does
require the reader to disable preemption, otherwise there is no guarantee that
they won't be scheduled out in the middle of the critical section, and the RCU
does only guarantee that a non schedulable reader will have finished by the time
the RCU period is over.

How do you plan to disable unvolountary preemption around the instructions you
want to overwrite ?


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]