On Mon, Nov 11, 2019 at 11:47:28AM -0800, Alexei Starovoitov wrote: > One more question. > What is the reason you stick to int3 style poking when 8 byte write is atomic? > Can text_poke() patch nop5 by combining the call/jmp5 insn with extra 3 bytes > after the nop and write 8 ? I think that question came up a while back (in one of the many static_call threads IIRC), and it basically boils down to there being far too many x86 uarchs to be sure of anything. Instruction fetch width is not always (well) specified and aligning instructions on i-fetch boundaries (or ensuring they don't cross) was deemed too fragile (also, it wastes space). This scheme is blessed by the hardware folks, and while it might be a little cumbersome, it isn't too horrible. Also, actually using that exception turns out to be beneficial for tracing text changes, see also this thread: https://lkml.kernel.org/r/20191025130000.13032-2-adrian.hunter@xxxxxxxxx