Messages in this thread | | | Date | Mon, 7 Sep 2009 13:06:19 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 0/4] RFC: jump label - (tracepoint optimizations) |
| |
* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote: > * Jason Baron (jbaron@redhat.com) wrote: [...] > > Solution: > > > > In discussing this problem with Roland McGrath and Richard Henderson, we came > > up with a new 'asm goto' statement that allows branching to a label. Thus, this > > patch set introdues a 'STATIC_JUMP_IF()' macro as follows: > > > > #ifdef HAVE_STATIC_JUMP > > > > #define STATIC_JUMP_IF(tag, label, cond) \ > > asm goto ("1:" /* 5-byte insn */ \ > > P6_NOP5 \ > > Hrm, be careful there. P6_NOP5 is not always a single instruction. If > you are preempted in the middle of it, bad things could happen, even > with stop_machine, if you iret in the middle the of the new jump > instruction. It could cause an illegal instruction fault. You should use > an atomic nop5. I think the function tracer already does, since I > told Steven about this exact issue. >
Just to clarify this statement:
P6_NOP5 happens to be an atomic nop, but nothing states this requirement in arch/x86/include/asm/nops.h. Other 5-bytes nops are defined as multiple instructions (e.g. 2 bytes + 3 bytes nops). So I recommend to create a family of ATOMIC_P6_NOP5 (and other ATOMIC_*_NOP5 defines) to document this atomicity requirement.
Ftrace could probably handle this more gracefully than it does at the moment. It basically assumes that P6_NOP5 is atomic, and falls back on a 5-bytes jmp if it detects that P6_NOP5 faults.
That's coherent with the "TODO: check the cpuid to determine the best nop."
present in x86 ftrace.c.
So, at the very least, if we rely on nops.h having a single-instruction P6_NOP5 5 bytes nop, a comment to that effect should be added to nops.h.
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |