Re: [PATCH 1/1] x86: fix text_poke

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Andi Kleen (andi@firstfloor.org) wrote:
> On Fri, Apr 25, 2008 at 09:06:37AM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Fri, 25 Apr 2008, Andi Kleen wrote:
> > > 
> > > So all these checks can be just removed.
> > 
> > Quite frankly, I'd rather tighten them up. All the callers actually seem 
> > to do just a single-byte one.
> 
> I think Mathieu did them to prepare for his immediate values which
> need to write more bytes (although actually it would be quite
> possible to have immediate values only for byte immediates too)
> 
> But that code needs much more infrastructure anyways.
> 

Yes, the immediate values, in general, only need to do atomic writes,
because I have taken care of placing the mov instruction in the correct
alignment so its immediate value happens to be aligned in memory.
However, the latest optimisation I did to change a conditional branch
into a jump when the correct code pattern is detected :

mov, test, bne short
into a
nop2, nop2, nop1, jmp short

or

mov, test, bne near
into a
nop2, nop2, nop1, jmp near

"replace_instruction_safe" is used for that. It puts a breakpoint in
lieue of each instruction's first byte before changing the rest of the
(potentially non aligned) instruction non atomically, and only then,
after issuing a sync_core on every CPUs to flush the trace cache, does
it put back the first byte, so it's done safely wrt intel's erratas
regarding code modification on SMP. Also note that it changes a 6 bytes
branch instruction into a 1 byte nop + 5 byte jump in the near jump
case, which is ok : you can split an instruction in multiple smaller
instructions safely on a live system wrt any execution context, but the
opposite is _not_ ok, since there could be a return address pointing in
the middle of the grouped instructions sitting on some other kernel
thread or interrupt stack (we should also take into account hypervisor
interaction here).

Mathieu


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68