From: Peter Zijlstra <peterz@infradead.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
"David S. Miller" <davem@davemloft.net>,
David Daney <david.daney@cavium.com>,
Michael Ellerman <michael@ellerman.id.au>,
Jan Glauber <jang@linux.vnet.ibm.com>,
Jason Baron <jbaron@redhat.com>,
the arch/x86 maintainers <x86@kernel.org>,
Xen Devel <xen-devel@lists.xensource.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH RFC V4 06/10] jump_label: add arch_jump_label_transform_static() to optimise non-live code updates
Date: Thu, 13 Oct 2011 12:32:34 +0200 [thread overview]
Message-ID: <1318501954.24856.5.camel@twins> (raw)
In-Reply-To: <16f652166605c973e9817177b6ba6a081e3e5b3f.1318464413.git.jeremy.fitzhardinge@citrix.com>
On Wed, 2011-10-12 at 17:08 -0700, Jeremy Fitzhardinge wrote:
> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>
> When updating a newly loaded module, the code is definitely not yet
> executing on any processor, so it can be updated with no need for any
> heavyweight synchronization.
>
> This patch adds arch_jump_label_static() which is implemented as
> arch_jump_label_transform() by default, but architectures can override
> it if it avoids, say, a call to stop_machine().
>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Acked-by: Jason Baron <jbaron@redhat.com>
> ---
> include/linux/jump_label.h | 2 ++
> kernel/jump_label.c | 18 +++++++++++++++---
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 12e804e..56594e4 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -45,6 +45,8 @@ extern void jump_label_lock(void);
> extern void jump_label_unlock(void);
> extern void arch_jump_label_transform(struct jump_entry *entry,
> enum jump_label_type type);
> +extern void arch_jump_label_transform_static(struct jump_entry *entry,
> + enum jump_label_type type);
> extern int jump_label_text_reserved(void *start, void *end);
> extern void jump_label_inc(struct jump_label_key *key);
> extern void jump_label_dec(struct jump_label_key *key);
> diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> index 059202d5..ff2028f 100644
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -104,6 +104,18 @@ static int __jump_label_text_reserved(struct jump_entry *iter_start,
> return 0;
> }
>
> +/*
> + * Update code which is definitely not currently executing.
> + * Architectures which need heavyweight synchronization to modify
> + * running code can override this to make the non-live update case
> + * cheaper.
> + */
> +void __weak arch_jump_label_transform_static(struct jump_entry *entry,
> + enum jump_label_type type)
> +{
> + arch_jump_label_transform(entry, type);
> +}
> +
> static void __jump_label_update(struct jump_label_key *key,
> struct jump_entry *entry,
> struct jump_entry *stop, int enable)
> @@ -135,8 +147,8 @@ static __init int jump_label_init(void)
> struct jump_label_key *iterk;
>
> iterk = (struct jump_label_key *)(unsigned long)iter->key;
> - arch_jump_label_transform(iter, jump_label_enabled(iterk) ?
> - JUMP_LABEL_ENABLE : JUMP_LABEL_DISABLE);
> + arch_jump_label_transform_static(iter, jump_label_enabled(iterk) ?
> + JUMP_LABEL_ENABLE : JUMP_LABEL_DISABLE);
> if (iterk == key)
> continue;
>
> @@ -208,7 +220,7 @@ void jump_label_apply_nops(struct module *mod)
> return;
>
> for (iter = iter_start; iter < iter_stop; iter++)
> - arch_jump_label_transform(iter, JUMP_LABEL_DISABLE);
> + arch_jump_label_transform_static(iter, JUMP_LABEL_DISABLE);
> }
>
So I got myself a little confused wrt the early jump_label_apply_nops()
call and the MODULE_COMING notifiers.
It looks to me like jump_label_apply_nops() is called way early and is
in fact called before _any_ of the module code has had a chance of
running. However it simply NOPs out all jump_labels.
The jump_label_add_module() thing, which is ran on the MODULE_COMING
callback will then set up stuff and do the proper patch-up.
Now the only bit of the module text that can be ran between those two
calls appears to be the module argument parsing stuff, but since
jump_labels are non-functional it can't rely on them, so why do we do
the early patch up again?
next prev parent reply other threads:[~2011-10-13 10:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 0:08 [PATCH RFC V4 00/10] jump-label: allow early jump_label_enable() Jeremy Fitzhardinge
[not found] ` <cover.1318464413.git.jeremy.fitzhardinge@citrix.com>
2011-10-13 0:08 ` [PATCH RFC V4 01/10] jump_label: use proper atomic_t initializer Jeremy Fitzhardinge
2011-10-13 0:08 ` [PATCH RFC V4 02/10] stop_machine: make stop_machine safe and efficient to call early Jeremy Fitzhardinge
2011-10-13 0:08 ` [PATCH RFC V4 03/10] jump_label: if a key has already been initialized, don't nop it out Jeremy Fitzhardinge
2011-10-13 0:08 ` [PATCH RFC V4 04/10] x86/jump_label: drop arch_jump_label_text_poke_early() Jeremy Fitzhardinge
2011-10-13 10:15 ` Peter Zijlstra
2011-10-13 0:08 ` [PATCH RFC V4 05/10] sparc/jump_label: " Jeremy Fitzhardinge
2011-10-13 0:08 ` [PATCH RFC V4 06/10] jump_label: add arch_jump_label_transform_static() to optimise non-live code updates Jeremy Fitzhardinge
2011-10-13 10:32 ` Peter Zijlstra [this message]
2011-10-13 13:54 ` Jason Baron
2011-10-13 15:29 ` Peter Zijlstra
2011-10-13 15:55 ` Jason Baron
2011-10-13 16:32 ` Peter Zijlstra
2011-10-13 0:08 ` [PATCH RFC V4 07/10] s390/jump-label: add arch_jump_label_transform_static() Jeremy Fitzhardinge
2011-10-13 0:08 ` [PATCH RFC V4 08/10] x86/jump_label: " Jeremy Fitzhardinge
2011-10-13 10:36 ` Peter Zijlstra
2011-10-13 0:08 ` [PATCH RFC V4 09/10] x86/jump_label: use GENERIC_NOP5_ATOMIC instead of jmp5 +0 Jeremy Fitzhardinge
2011-10-13 15:40 ` H. Peter Anvin
2011-10-13 16:50 ` Jeremy Fitzhardinge
2011-10-14 21:52 ` H. Peter Anvin
2011-10-13 16:57 ` Jeremy Fitzhardinge
2011-10-13 18:37 ` Steven Rostedt
2011-10-14 21:53 ` H. Peter Anvin
2011-10-15 0:22 ` Steven Rostedt
2011-10-14 21:53 ` H. Peter Anvin
2011-10-13 0:08 ` [PATCH RFC V4 10/10] jump-label: initialize jump-label subsystem much earlier Jeremy Fitzhardinge
2011-10-13 10:43 ` Peter Zijlstra
2011-10-13 13:59 ` Jason Baron
2011-10-13 16:56 ` Jeremy Fitzhardinge
2011-10-14 21:51 ` Jeremy Fitzhardinge
2011-10-15 8:42 ` Peter Zijlstra
2011-10-16 1:52 ` Jeremy Fitzhardinge
2011-10-18 11:02 ` Peter Zijlstra
2011-10-25 17:56 ` Jeremy Fitzhardinge
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=1318501954.24856.5.camel@twins \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=david.daney@cavium.com \
--cc=hpa@zytor.com \
--cc=jang@linux.vnet.ibm.com \
--cc=jbaron@redhat.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ellerman.id.au \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/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