Re: [RFC] [PATCH 1/2 v2] x86: introduce int3-based instructionpatching

[Jiri Kosina]

On Wed, 10 Jul 2013, H. Peter Anvin wrote:

> > If any CPU instruction execution would collide with the patching,
> > it'd be trapped by the int3 breakpoint and redirected to the provided
> > "handler" (which would typically mean just skipping over the patched
> > region, acting as "nop" has been there, in case we are doing nop -> jump
> > and jump -> nop transitions).
> > 
> 
> I'm wondering if it would be easier/more general to just return to the
> instruction.  The "more general" bit would allow this to be used for
> other things, like alternatives, 

As Boris already pointed out, this is not really that interesting, as it's 
being done through text_poke_early(), which is rather a different story 
anyway.

> and perhaps eventually dynamic call patching.

Umm ... could you please elaborate either what exactly do you mean by 
that, or why it can't be used currently as-is?

> Returning to the instruction will, in effect, be a busy-wait for the 
> faulted CPU until the patch is complete; more or less what stop_machine 
> would do, but only for a CPU which actually strays into the affected 
> region.

To be honest, I fail to see a clear advantage ... we don't avoid any extra 
IPI by it, and wrt. "correctness", the end result is the same.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/