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


> 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.

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.

-Andi


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