[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190110205226.iburt6mrddsxnjpk@treble>
Date: Thu, 10 Jan 2019 14:52:26 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Andy Lutomirski <luto@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Jason Baron <jbaron@...mai.com>, Jiri Kosina <jkosina@...e.cz>,
David Laight <David.Laight@...LAB.COM>,
Borislav Petkov <bp@...en8.de>,
Julia Cartwright <julia@...com>, Jessica Yu <jeyu@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Nadav Amit <namit@...are.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Edward Cree <ecree@...arflare.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: [PATCH v3 0/6] Static calls
On Thu, Jan 10, 2019 at 09:30:23PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 09, 2019 at 04:59:35PM -0600, Josh Poimboeuf wrote:
> > With this version, I stopped trying to use text_poke_bp(), and instead
> > went with a different approach: if the call site destination doesn't
> > cross a cacheline boundary, just do an atomic write. Otherwise, keep
> > using the trampoline indefinitely.
>
> > - Get rid of the use of text_poke_bp(), in favor of atomic writes.
> > Out-of-line calls will be promoted to inline only if the call sites
> > don't cross cache line boundaries. [Linus/Andy]
>
> Can we perserve why text_poke_bp() didn't work? I seem to have forgotten
> again. The problem was poking the return address onto the stack from the
> int3 handler, or something along those lines?
Right, emulating a call instruction from the #BP handler is ugly,
because you have to somehow grow the stack to make room for the return
address. Personally I liked the idea of shifting the iret frame by 16
bytes in the #DB entry code, but others hated it.
So many bad-but-not-completely-unacceptable options to choose from.
--
Josh
Powered by blists - more mailing lists