[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiPrOd_yM5NGHQDE3AFtNWqV=MDFno2xgZOYV3jwGQU4w@mail.gmail.com>
Date: Wed, 25 Mar 2020 11:26:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andy Lutomirski <luto@...capital.net>,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Jason Baron <jbaron@...mai.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, Nadav Amit <namit@...are.com>,
Peter Anvin <hpa@...or.com>,
Andrew Lutomirski <luto@...nel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RESEND][PATCH v3 14/17] static_call: Add static_cond_call()
On Wed, Mar 25, 2020 at 11:13 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> To clarify; the problem is a task getting preempted with its RIP at the
> RET. Then when we rewrite the text to be a CALL/JMP.d32 it will read
> garbage (1 byte into the displacement of the instruction) instead of a
> RET when it resumes.
Yeah, I realized it when you mentioned it. I was trying to come up
with some clever way to avoid it, but can't see anything.
I can come up with insane models - you could replace the xor;ret
sequence with a jump to a trampoline where you've aligned the target
trampoline so that the third byte in the "jmp xxx" remains a 'ret'
instruction. Then replace _that_ one with a "call_rcu()" callback.
Wild handwaving of "I'm sure this could be made to work".
But nothing remotely sane comes to mind.
Linus
Powered by blists - more mailing lists