mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	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>
Subject: Re: [RFC PATCH 1/3] static_call: Add static call infrastructure
Date: Fri, 9 Nov 2018 13:35:05 -0600	[thread overview]
Message-ID: <20181109193505.5p5iddrtgpk2cpb4@treble> (raw)
In-Reply-To: <20181109133337.63487e3a@gandalf.local.home>

On Fri, Nov 09, 2018 at 01:33:37PM -0500, Steven Rostedt wrote:
> > +config HAVE_STATIC_CALL_OPTIMIZED
> > +	bool
> > +
> > +config HAVE_STATIC_CALL_UNOPTIMIZED
> > +	bool
> > +
> 
> Let's also have
> 
> config HAVE_STATIC_CALL
> 	def_bool Y
> 	depends on HAVE_STATIC_CALL_OPTIMIZED || HAVE_STATIC_CALL_UNOPTIMIZED
>
> > +#if defined(CONFIG_HAVE_STATIC_CALL_OPTIMIZED) || \
> > +    defined(CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED)
> 
> Now we can have:
> 
> #ifdef CONFIG_HAVE_STATIC_CALL

Yeah, that's better.

> > +#define DECLARE_STATIC_CALL(key, func)					\
> > +	extern struct static_call_key key;				\
> > +	extern typeof(func) STATIC_CALL_TRAMP(key);			\
> > +	/* Preserve the ELF symbol so objtool can access it: */		\
> > +	__ADDRESSABLE(key)
> 
> Does the __ADDRESSABLE(key) need to be in the DECLARE part?
> If so, there needs to be more explanation than just the comment above
> it.

For each call site, objtool creates a struct in .static_call_sites:

	struct static_call_site {
		s32 addr;
		s32 key;
	};

In order to do that, it needs to create a relocation which references
the key symbol.  If the key is defined in another .o file, then the
current .o will not have an ELF symbol associated with the key.  The
__ADDRESSABLE(key) thing tells GCC to leave the key symbol in the .o
file, even though it's not referenced anywhere.  That makes objtool's
job easier, so it doesn't have to edit the symbol table.

I could add a comment saying as much, though it's hard to explain it in
fewer words than I just did :-)

> > +	/*
> > +	 * If called before init, leave the call sites unpatched for now.
> > +	 * In the meantime they'll continue to call the temporary trampoline.
> > +	 */
> > +	if (!static_call_initialized)
> > +		goto done;
> > +
> > +	list_for_each_entry(mod, &key->site_mods, list) {
> 
> Since I'm expecting a lot of sites, I'm wondering if we should just do
> this as an array, like I do with the ftrace call sites.
> 
> But this can be an enhancement for later. Let's focus on getting this
> working first.

But it's not a static list.  It can grow/shrink as modules are
loaded/unload.

> 
> > +		if (!mod->sites) {
> > +			/*
> > +			 * This can happen if the static call key is defined in
> > +			 * a module which doesn't use it.
> > +			 */
> > +			continue;
> > +		}
> > +
> > +		stop = __stop_static_call_sites;
> > +
> > +#ifdef CONFIG_MODULES
> > +		if (mod->mod) {
> 
> BTW, "mod" is an unfortunate name.

True.  I'll change it to 'site_mod'.

> 
> > +			stop = mod->mod->static_call_sites +
> > +			       mod->mod->num_static_call_sites;
> > +		}
> > +#endif
> > +
> > +		for (site = mod->sites;
> > +		     site < stop && static_call_key(site) == key; site++) {
> > +			unsigned long addr = static_call_addr(site);
> > +
> > +			if (!mod->mod && init_section_contains((void *)addr, 1))
> > +				continue;
> > +			if (mod->mod && within_module_init(addr, mod->mod))
> > +				continue;
> > +
> 
> 
> So what's the reason for skipping init calls?

This is the runtime changing code (static_call_update).  Presumably the
init sections no longer exist and we shouldn't write to any (former)
call sites there.

That's probably a dangerous assumption though...  If
static_call_update() were called early, some init code might not get
patched and then call into the wrong function.

I'm thinking we should just disallow static call sites in init sections.
I can't think of a good reason why they would be needed in init code.
We can WARN when detecting them during boot / module init.

-- 
Josh

  reply	other threads:[~2018-11-09 19:35 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 21:15 [PATCH RFC 0/3] Static calls Josh Poimboeuf
2018-11-08 21:15 ` [RFC PATCH 1/3] static_call: Add static call infrastructure Josh Poimboeuf
2018-11-09  9:51   ` Ard Biesheuvel
2018-11-09 14:55     ` Josh Poimboeuf
2018-11-09 13:39   ` Ard Biesheuvel
2018-11-09 15:10     ` Josh Poimboeuf
2018-11-09 15:14       ` Ard Biesheuvel
2018-11-09 17:25         ` Ard Biesheuvel
2018-11-09 17:31           ` Josh Poimboeuf
2018-11-09 17:33             ` Ard Biesheuvel
2018-11-09 17:46               ` Josh Poimboeuf
2018-11-09 17:52                 ` Ard Biesheuvel
2018-11-09 17:53                   ` Ard Biesheuvel
2018-11-09 19:03                     ` Josh Poimboeuf
2018-11-09 19:12                       ` Ard Biesheuvel
2018-11-09 17:33             ` Josh Poimboeuf
2018-11-09 18:33   ` Steven Rostedt
2018-11-09 19:35     ` Josh Poimboeuf [this message]
2018-11-09 19:57       ` Steven Rostedt
2018-11-09 20:34         ` Josh Poimboeuf
2018-11-10  5:10           ` Steven Rostedt
2018-11-10 11:58             ` Ard Biesheuvel
2018-11-10 13:09               ` Steven Rostedt
2018-11-12  3:07                 ` Josh Poimboeuf
2018-11-12  4:39                   ` Ard Biesheuvel
2018-11-12  4:56                     ` Josh Poimboeuf
2018-11-12  5:02                       ` Ard Biesheuvel
2018-11-10 11:56           ` Ard Biesheuvel
2018-11-08 21:15 ` [RFC PATCH 2/3] x86/static_call: Add x86 unoptimized static call implementation Josh Poimboeuf
2018-11-08 21:15 ` [RFC PATCH 3/3] x86/static_call: Add optimized static call implementation for 64-bit Josh Poimboeuf
2018-11-08 21:24 ` [PATCH RFC 0/3] Static calls Josh Poimboeuf
2018-11-09  7:28 ` Ingo Molnar
2018-11-09  7:50   ` Ingo Molnar
2018-11-09 13:50   ` Ard Biesheuvel
2018-11-09 15:20     ` Josh Poimboeuf
2018-11-10 23:20     ` Peter Zijlstra
2018-11-11 13:42       ` Ard Biesheuvel
2018-11-11 14:25         ` Peter Zijlstra
2018-11-09 14:45   ` Josh Poimboeuf
2018-11-12  5:02     ` Ingo Molnar
2018-11-12  5:30       ` Josh Poimboeuf
2018-11-12  9:39         ` Ard Biesheuvel
2018-11-12 22:52           ` Josh Poimboeuf
2018-11-12 17:03         ` Steven Rostedt
2018-11-12 22:56           ` Josh Poimboeuf
2018-11-12  5:34       ` Andy Lutomirski
2018-11-09 15:16   ` Andy Lutomirski
2018-11-09 15:21     ` Josh Poimboeuf
2018-11-09 16:41       ` Josh Poimboeuf
2018-11-09 18:42         ` Steven Rostedt
2018-11-09 19:05           ` Andy Lutomirski
2018-11-09 19:37             ` Steven Rostedt
2018-11-09 19:44               ` Josh Poimboeuf
2018-11-09 19:59                 ` Steven Rostedt
2018-11-09 20:36                   ` Josh Poimboeuf
2018-11-10 15:13             ` Masami Hiramatsu
2018-11-09 20:53     ` Rasmus Villemoes

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=20181109193505.5p5iddrtgpk2cpb4@treble \
    --to=jpoimboe@redhat.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=jbaron@akamai.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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

Powered by JetHome