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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function"
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20181008072134.GB5663@hirez.programming.kicks-ass.net>
Date:   Mon, 8 Oct 2018 01:33:14 -0700
Cc:     Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Matthew Helsley <mhelsley@vmware.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Jason Baron <jbaron@akamai.com>, Jiri Kosina <jkosina@suse.cz>,
        ard.biesheuvel@linaro.org, Andy Lutomirski <luto@kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9379DDB-3210-407C-8157-8DA980944F8C@amacapital.net>
References: <20181006015110.653946300@goodmis.org> <20181006015720.634688468@goodmis.org> <20181006121211.GA5663@hirez.programming.kicks-ass.net> <20181006093905.46276505@vmware.local.home> <20181008072134.GB5663@hirez.programming.kicks-ass.net>
To:     Peter Zijlstra <peterz@infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Oct 8, 2018, at 12:21 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>=20
>> On Sat, Oct 06, 2018 at 09:39:05AM -0400, Steven Rostedt wrote:
>> On Sat, 6 Oct 2018 14:12:11 +0200
>> Peter Zijlstra <peterz@infradead.org> wrote:
>>=20
>>>> On Fri, Oct 05, 2018 at 09:51:11PM -0400, Steven Rostedt wrote:
>>>> +#define arch_dynfunc_trampoline(name, def)    \
>>>> +    asm volatile (                \
>>>> +    ".globl dynfunc_" #name "; \n\t"    \
>>>> +    "dynfunc_" #name ": \n\t"        \
>>>> +    "jmp " #def " \n\t"            \
>>>> +    ".balign 8 \n \t"            \
>>>> +    : : : "memory" ) =20
>>>=20
>>> Bah, what is it with you people and trampolines. Why can't we, just like=

>>> jump_label, patch the call directly?
>>>=20
>>> The whole call+jmp thing is silly, don't do that. It just wrecks I$ and
>>> is slower for no real reason afaict.
>>=20
>> My first attempt was to do just that. But to add a label at the
>> call site required handling all the parameters too. See my branch:
>> ftrace/jump_function-v1 for how ugly it got (and it didn't work).
>=20
> Can't we hijack the relocation records for these functions before they
> get thrown out in the (final) link pass or something?

I could be talking out my arse here, but I thought we could do this, too, th=
en changed my mind.  The relocation records give us the location of the call=
 or jump operand, but they don=E2=80=99t give the address of the beginning o=
f the instruction. If the instruction crosses a cache line boundary, don=E2=80=
=99t we need to use the int3 patching trick?  And that requires knowing whic=
h byte to patch with int3.

Or am I wrong and can the CPUs we care about correctly handle a locked write=
 to part of an instruction that crosses a cache line boundary?=