From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Arjan van de Ven <arjan@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org,
"2nddept-manager@sdl.hitachi.co.jp"
<2nddept-manager@sdl.hitachi.co.jp>
Subject: Re: [RFC PATCH] x86: stop machine text poke should issue sync core
Date: Thu, 03 Mar 2011 14:27:54 +0900 [thread overview]
Message-ID: <4D6F26DA.5040403@hitachi.com> (raw)
In-Reply-To: <20110228152405.GA7064@Krystal>
(2011/03/01 0:24), Mathieu Desnoyers wrote:
> Intel Archiecture Software Developer's Manual section 7.1.3 specifies that a
> core serializing instruction such as "cpuid" should be executed on _each_ core
> before the new instruction is made visible.
>
> Failure to do so can lead to unspecified behavior (Intel XMC erratas include
> General Protection Fault in the list), so we should avoid this at all cost.
>
> This problem can affect modified code executed by interrupt handlers after
> interrupt are re-enabled at the end of stop_machine, because no core serializing
> instruction is executed between the code modification and the moment interrupts
> are reenabled.
>
> Because stop_machine_text_poke performs the text modification from the first CPU
> decrementing stop_machine_first, modified code executed in thread context is
> also affected by this problem. To explain why, we have to split the CPUs in two
> categories: the CPU that initiates the text modification (calls text_poke_smp)
> and all the others. The scheduler, executed on all other CPUs after
> stop_machine, issues an "iret" core serializing instruction, and therefore
> handles core serialization for all these CPUs. However, the text modification
> initiator can continue its execution on the same thread and access the modified
> text without any scheduler call. Given that the CPU that initiates the code
> modification is not guaranteed to be the one actually performing the code
> modification, it falls into the XMC errata.
Thanks Mathieu!
It seems reasonable change. At least I'm OK :)
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Peter Zijlstra <peterz@infradead.org>
> CC: Arjan van de Ven <arjan@infradead.org>
> CC: "H. Peter Anvin" <hpa@zytor.com>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Ingo Molnar <mingo@elte.hu>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Andi Kleen <andi@firstfloor.org>
> CC: Frederic Weisbecker <fweisbec@gmail.com>
> CC: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> ---
> arch/x86/kernel/alternative.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> Index: linux-2.6-lttng/arch/x86/kernel/alternative.c
> ===================================================================
> --- linux-2.6-lttng.orig/arch/x86/kernel/alternative.c
> +++ linux-2.6-lttng/arch/x86/kernel/alternative.c
> @@ -612,6 +612,12 @@ static int __kprobes stop_machine_text_p
>
> flush_icache_range((unsigned long)tpp->addr,
> (unsigned long)tpp->addr + tpp->len);
> + /*
> + * Intel Archiecture Software Developer's Manual section 7.1.3 specifies
> + * that a core serializing instruction such as "cpuid" should be
> + * executed on _each_ core before the new instruction is made visible.
> + */
> + sync_core();
> return 0;
> }
>
--
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2011-03-03 5:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 15:24 [RFC PATCH] x86: stop machine text poke should issue sync core Mathieu Desnoyers
2011-03-03 5:27 ` Masami Hiramatsu [this message]
2011-03-03 6:10 ` H. Peter Anvin
2011-03-03 7:02 ` Masami Hiramatsu
2011-03-03 15:53 ` Mathieu Desnoyers
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=4D6F26DA.5040403@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=2nddept-manager@sdl.hitachi.co.jp \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.