Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

[Andy Lutomirski]

> On Nov 29, 2018, at 9:29 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>> 
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>> 
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction yourself to be the right call, by looking it up in the
>>> "what needs to be fixed" tables.
>> 
>> I thought that too.  I think it deadlocks. CPU A does text_poke_bp().  CPU B is waiting for a spinlock with IRQs off.  CPU C holds the spinlock and hits the int3.  The int3 never goes away because CPU A is waiting for CPU B to handle the sync_core IPI.
>> 
>> Or do you think we can avoid the IPI while the int3 is there?
> 
> I'm handwaving and thinking that CPU C that hits the int3 can just fix
> up the instruction directly in its own caches, and return.
> 
> Yes, it does what he "text_poke" *will* do (so now the instruction
> gets rewritten _twice_), but who cares? It's idempotent.
> 
> 

But itâs out of order. Iâm not concerned about the final IPI â Iâm concerned about the IPI after the int3 write and before the int3 is removed again. If one CPU replaces 0xcc with 0xe8, another CPU could observe that before the last couple bytes of the call target are written and observed by all CPUs.