> On Jan 3, 2019, at 2:48 PM, Andi Kleen <a...@linux.intel.com> wrote: > >> Ok… I’ll try to think about another solution. Just note that this is just >> used as a hint to avoid unnecessary lookups. (IOW, nothing will break if the >> prefix is used.) > > Are you sure actually? > > The empty prefix could mean 8bit register accesses. > >>> You're doing the equivalent of patching a private system call >>> into your own kernel without working with upstream, don't do that. >> >> I don’t understand this comment though. Can you please explain? > > Instruction encoding = system call ABI > Upstream = CPU vendors > > Early in Linux's history, naive Linux distribution vendors patched in their > own > private system calls without waiting for upstream to define an ABI, which > caused > endless compatibility problems. These days this is very frowned upon. > >>> Better to find some other solution to do the restart. >>> How about simply using a per cpu variable? That should be cheaper >>> anyways. >> >> The problem is that the per-cpu variable needs to be updated after the call >> is executed, when we are already not in the context of the “injected” code. >> I can increase it before the call, and decrease it after return - but this >> can create (in theory) long periods in which the code is “unpatchable”, >> increase the code size and slow performance. >> >> Anyhow, I’ll give more thought. Ideas are welcomed. > > Write the address of the instruction into the per cpu variable.
Thanks for the explanations. I don’t think it would work (e.g., IRQs). I can avoid generalizing and just detect the "magic sequence” of the code, but let me give it some more thought.
