Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <cover.1547073843.git.jpoimboe@redhat.com> <20190110203023.GL2861@worktop.programming.kicks-ass.net>
 <20190110205226.iburt6mrddsxnjpk@treble> <CAHk-=whR7LzKcuB9Z2km1T25DUkJcbE9rNhCzApAPADbDqMhmQ@mail.gmail.com>
 <CALCETrWBwTVHWXahVXMMBL4QA1f+YdKgv1XANXPsk86FjFFH2Q@mail.gmail.com>
 <B374297A-8298-4CED-8EC0-6A39BDBA5F05@vmware.com> <20190111151525.tf7lhuycyyvjjxez@treble>
 <CAHk-=wjJm8DpCsw=Wno01q4VFqUeiLKE8QmbAtUJurYhn3jRqA@mail.gmail.com>
 <20190111200420.qtyffayxceysoarf@treble> <CAHk-=whLu9kG3dqgXUkCrNrTp0NVtdOOWxvonXTfhtq-krXo+Q@mail.gmail.com>
 <20190111203135.5clurevf34bkiy3o@treble>
In-Reply-To: <20190111203135.5clurevf34bkiy3o@treble>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 11 Jan 2019 12:46:39 -0800
Message-ID: <CAHk-=whKabsg3N4uHHFkHXXf_mi6=T2OvkC-OUNG8Lt-bsCjFg@mail.gmail.com>
Subject: Re: [PATCH v3 0/6] Static calls
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Nadav Amit <namit@vmware.com>, Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Jason Baron <jbaron@akamai.com>, Jiri Kosina <jkosina@suse.cz>,
        David Laight <David.Laight@aculab.com>,
        Borislav Petkov <bp@alien8.de>,
        Julia Cartwright <julia@ni.com>, Jessica Yu <jeyu@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Edward Cree <ecree@solarflare.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jan 11, 2019 at 12:31 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> I was referring to the fact that a single static call key update will
> usually result in patching multiple call sites.  But you're right, it's
> only 1-2 trampolines per text_poke_bp() invocation.  Though eventually
> we may want to batch all the writes like what Daniel has proposed for
> jump labels, to reduce IPIs.

Yeah, my suggestion doesn't allow for batching, since it would
basically generate one trampoline for every rewritten instruction.

> Regardless, the trampoline management seems more complex to me.  But
> it's easier to argue about actual code, so maybe I'll code it up to make
> it easier to compare solutions.

I do agree hat the stack games are likely "simpler" in one sense. I
just abhor playing those kinds of games with the entry code and entry
stack.

A small bit of extra complexity in the code that actually does the
rewriting would be much more palatable to me than the complexity in
the entry code. I prefer seeing the onus of complexity being on the
code that introduces the problem, not on a innocent bystander.

I'd like to say that our entry code actually looks fairly sane these
days.  I'd _like_ to say that, but I'd be lying through my teeth if I
did. The macros we use make any normal persons head spin.

The workaround for the stack corruption was fairly simple, but the
subtlety behind the *reason* for it was what made my hackles rise
about that code.

The x86 entry code is some of the nastiest in the kernel, I feel, with
all the subtle interactions about odd stack switches, odd CPU bugs
causing odd TLB switches, NMI interactions etc etc.

So I am fully cognizant that the workaround to shift the stack in the
entry code was just a couple of lines, and not very complicated.

And I agree that I may be a bit oversensitive about that area, but it
really is one of those places where I go "damn, I think I know some
low-level x86 stuff better than most, but that code scares *me*".

Which is why I'd accept a rather bigger complexity hit just about
anywhere else in the code...

               Linus