This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Andi Kleen <ak at suse dot de>
- To: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- Cc: Andi Kleen <ak at suse dot de>, Karim Yaghmour <karim at opersys dot com>,Masami Hiramatsu <masami dot hiramatsu at gmail dot com>,Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>,Roland McGrath <roland at redhat dot com>,Richard J Moore <richardj_moore at uk dot ibm dot com>,systemtap at sources dot redhat dot com, sugita at sdl dot hitachi dot co dot jp,Satoshi Oshima <soshima at redhat dot com>, michel dot dagenais at polymtl dot ca
- Date: Sat, 30 Jul 2005 17:55:26 +0200
- Subject: Re: Hitachi djprobe mechanism
- References: <42E83CEC.8040702@opersys.com> <f86b20530507280922819d927@mail.gmail.com> <42E90600.3040709@opersys.com> <20050728173515.GB18093@Krystal> <20050728110717.A30199@unix-os.sc.intel.com> <20050728183234.GC18093@Krystal> <20050728133456.A32210@unix-os.sc.intel.com> <20050729055308.GA4200@Krystal> <p73d5p2gi7o.fsf@bragg.suse.de> <20050729155025.GA357@Krystal>
> 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