From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
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 13:16:05 -0500 [thread overview]
Message-ID: <20181010181605.arsyjxwdztztrjih@treble> (raw)
In-Reply-To: <CALCETrUOaJ1dAsuX9bQO_+B4G6y5-FAb0=ZYA8QbtAEBZ6MxKg@mail.gmail.com>
On Wed, Oct 10, 2018 at 11:03:43AM -0700, Andy Lutomirski wrote:
> > +#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?
This is the magic needed for objtool to find all the call sites.
The variable itself isn't needed, but the .discard.static_call_tramps
entry is. Objtool reads that section to find out which function call
sites are targeted to a static call trampoline.
> > +#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.)
Yeah, that would be better. It would also allow trampoline function
pointers to work, which I think you mentioned elsewhere. And then I
shouldn't trample this code in __static_call_update() -- that was
already kind of nasty anyway.
> 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.
Good idea.
> > +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:
Yep.
> > + 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 :)
Oops :-)
--
Josh
next prev parent reply other threads:[~2018-10-10 18:16 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
2018-10-10 18:16 ` Josh Poimboeuf [this message]
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=20181010181605.arsyjxwdztztrjih@treble \
--to=jpoimboe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=dwmw2@infradead.org \
--cc=jbaron@akamai.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--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).