linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <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>,
	Jason Baron <jbaron@akamai.com>, Jiri Kosina <jkosina@suse.cz>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andrew Lutomirski <luto@kernel.org>
Subject: Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function"
Date: Wed, 10 Oct 2018 11:03:43 -0700	[thread overview]
Message-ID: <CALCETrUOaJ1dAsuX9bQO_+B4G6y5-FAb0=ZYA8QbtAEBZ6MxKg@mail.gmail.com> (raw)
In-Reply-To: <20181010175237.e7m3sldcu2maoqcq@treble>

On Wed, Oct 10, 2018 at 10:52 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Mon, Oct 08, 2018 at 11:57:50PM -0400, Steven Rostedt wrote:
> > On Mon, 8 Oct 2018 21:17:10 -0500
> > Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > > I'm not really convinced we need objtool for this, maybe I'll try
> > > whipping up a POC.
> >
> > Awesome!
> >
> > I wasn't thinking of actually having objtool itself perform this task,
> > but instead breaking the internals of objtool up into more of a generic
> > infrastructure, that recordmcount.c, objtool, and whatever this does
> > can use.
>
> So I had been thinking that we could find the call sites at runtime, by
> looking at the relocations.  But I managed to forget that vmlinux
> relocations are resolved during linking.  So yeah, some kind of tooling
> magic would be needed.
>
> I worked up a POC using objtool.  It doesn't *have* to be done with
> objtool, but since it's already reading/writing all the ELF stuff
> anyway, it was pretty easy to add this on.
>
> This patch has at least a few issues:
>
> - No module support.
>
> - For some reason, the sync_cores in text_poke_bp() don't always seem to
>   be working as expected.  Running this patch on my VM, the test code in
>   cmdline_proc_show() works *most* of the time, but it occasionally
>   branches off into the weeds.  I have no idea what the problem is yet.
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 9d329608913e..20ff5624dad7 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -865,6 +865,9 @@ config HAVE_ARCH_PREL32_RELOCATIONS
>           architectures, and don't require runtime relocation on relocatable
>           kernels.
>
> +config HAVE_ARCH_STATIC_CALL
> +       bool
> +
>  source "kernel/gcov/Kconfig"
>
>  source "scripts/gcc-plugins/Kconfig"
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5136a1281870..1a14c8f87876 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -128,6 +128,7 @@ config X86
>         select HAVE_ARCH_COMPAT_MMAP_BASES      if MMU && COMPAT
>         select HAVE_ARCH_PREL32_RELOCATIONS
>         select HAVE_ARCH_SECCOMP_FILTER
> +       select HAVE_ARCH_STATIC_CALL            if X86_64
>         select HAVE_ARCH_THREAD_STRUCT_WHITELIST
>         select HAVE_ARCH_TRACEHOOK
>         select HAVE_ARCH_TRANSPARENT_HUGEPAGE
> diff --git a/arch/x86/include/asm/static_call.h b/arch/x86/include/asm/static_call.h
> new file mode 100644
> index 000000000000..40fec631b760
> --- /dev/null
> +++ b/arch/x86/include/asm/static_call.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_STATIC_CALL_H
> +#define _ASM_STATIC_CALL_H
> +
> +#ifdef CONFIG_X86_64
> +
> +#include <linux/frame.h>
> +
> +void static_call_init(void);
> +extern void __static_call_update(void *tramp, void *func);
> +
> +#define DECLARE_STATIC_CALL(tramp, func)                               \
> +       extern typeof(func) tramp;                                      \
> +       static void __used __section(.discard.static_call_tramps)       \
> +               *__static_call_tramp_##tramp = tramp
> +

Confused.  What's the __static_call_tramp_##tramp variable for?  And
why is a DECLARE_ macro defining a variable?

> +#define DEFINE_STATIC_CALL(tramp, func)                                        \
> +       DECLARE_STATIC_CALL(tramp, func);                               \
> +       asm(".pushsection .text, \"ax\"                         \n"     \
> +           ".align 4                                           \n"     \
> +           ".globl " #tramp "                                  \n"     \
> +           ".type " #tramp ", @function                        \n"     \
> +           #tramp ":                                           \n"     \
> +           "jmp " #func "                                      \n"     \

I think this would be nicer as an indirect call that gets patched to a
direct call so that the update mechanism works even before it's
initialized.  (Currently static_branch blows up horribly if you try to
update one too early, and that's rather annoying IMO.)

Also, I think you're looking for "jmp.d32", which is available in
newer toolchains.  For older toolchains, you could use .byte 0xe9 or
you could use a different section (I think) to force a real 32-bit
jump.

> +void __init static_call_init(void)
> +{
> +       struct static_call_entry *entry;
> +       unsigned long insn, tramp, func;
> +       unsigned char insn_opcode, tramp_opcode;
> +       s32 call_dest;
> +
> +       for (entry = __start_static_call_table;
> +            entry < __stop_static_call_table; entry++) {
> +
> +               insn = (long)entry->insn + (unsigned long)&entry->insn;
> +               tramp = (long)entry->tramp + (unsigned long)&entry->tramp;
> +
> +               insn_opcode = *(unsigned char *)insn;
> +               if (insn_opcode != 0xe8 && insn_opcode != 0xe9) {
> +                       WARN_ONCE(1, "unexpected static call insn opcode %x at %pS",
> +                                 insn_opcode, (void *)insn);
> +                       continue;
> +               }
> +
> +               tramp_opcode = *(unsigned char *)tramp;
> +               if (tramp_opcode != 0xeb && tramp_opcode != 0xe9) {
> +                       WARN_ONCE(1, "unexpected trampoline jump opcode %x at %ps",
> +                                tramp_opcode, (void *)tramp);
> +                       continue;
> +               }
> +
> +               if (tramp_opcode == 0xeb)
> +                       func = *(s8 *)(tramp + 1) + (tramp + 2);

I realize you expect some instances of 0xeb due to the assembler
messing you up (see above), but this seems a bit too permissive, since
a 0xeb without the appropriate set of NOPs is going to explode.  And:

> +               else
> +                       func = *(s32 *)(tramp + 1) + (tramp + 5);
> +
> +               call_dest = (long)(func) - (long)(insn + 5);
> +
> +               printk("static_call_init: poking %lx at %lx\n", (unsigned long)call_dest, (insn+1));
> +
> +               text_poke_early((void *)(insn + 1), &call_dest, 4);

If you really are going to rewrite an 8-bit jump to a 32-bit jump, I
think you need to actually patch the opcode byte :)

  reply	other threads:[~2018-10-10 18:04 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-06  1:51 [POC][RFC][PATCH 0/2] PROOF OF CONCEPT: Dynamic Functions (jump functions) Steven Rostedt
2018-10-06  1:51 ` [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function" Steven Rostedt
2018-10-06  2:00   ` Steven Rostedt
2018-10-06  2:02   ` Steven Rostedt
2018-10-06  2:03   ` Steven Rostedt
2018-10-06 15:15     ` Steven Rostedt
2018-10-06 12:12   ` Peter Zijlstra
2018-10-06 13:39     ` Steven Rostedt
2018-10-06 15:13       ` Andy Lutomirski
2018-10-06 15:16         ` Steven Rostedt
2018-10-08  7:21       ` Peter Zijlstra
2018-10-08  8:33         ` Andy Lutomirski
2018-10-08 15:57           ` Peter Zijlstra
2018-10-08 16:29             ` Andy Lutomirski
2018-10-08 16:39               ` Steven Rostedt
2018-10-08 16:39               ` Peter Zijlstra
2018-10-08 17:25                 ` Andy Lutomirski
2018-10-08 17:30                   ` Ard Biesheuvel
2018-10-08 17:42                     ` Andy Lutomirski
2018-10-08 17:44                     ` Jiri Kosina
2018-10-08 17:45                       ` Ard Biesheuvel
2018-10-08 17:47                       ` Andy Lutomirski
2018-10-09  2:17               ` Josh Poimboeuf
2018-10-09  3:57                 ` Steven Rostedt
2018-10-10 17:52                   ` Josh Poimboeuf
2018-10-10 18:03                     ` Andy Lutomirski [this message]
2018-10-10 18:16                       ` Josh Poimboeuf
2018-10-10 18:17                         ` Josh Poimboeuf
2018-10-10 21:13                           ` Andy Lutomirski
2018-10-11  3:07                             ` Josh Poimboeuf
2018-10-11 12:52                               ` Josh Poimboeuf
2018-10-11 16:20                                 ` Andy Lutomirski
2018-10-10 18:33                         ` Josh Poimboeuf
2018-10-10 18:56                           ` Steven Rostedt
2018-10-10 20:16                             ` Josh Poimboeuf
2018-10-10 20:57                               ` Andy Lutomirski
2018-10-08 16:31             ` Steven Rostedt
2018-10-08 11:30       ` Ard Biesheuvel
2018-10-09  3:44   ` Masami Hiramatsu
2018-10-09  3:55     ` Steven Rostedt
2018-10-09 16:04       ` Masami Hiramatsu
2018-10-09  8:59     ` David Laight
2018-10-06  1:51 ` [POC][RFC][PATCH 2/2] tracepoints: Implement it with dynamic functions Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrUOaJ1dAsuX9bQO_+B4G6y5-FAb0=ZYA8QbtAEBZ6MxKg@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=jbaron@akamai.com \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhelsley@vmware.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).