lkml.org 
[lkml]   [2011]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[14/78] x86: stop_machine_text_poke() should issue sync_core()
    2.6.38-stable review patch.  If anyone has any objections, please let us know.

    ------------------

    From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

    commit 0e00f7aed6af21fc09b2a94d28bc34e449bd3a53 upstream.

    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.

    Q: Isn't this executed from an IPI handler, which will return with IRET (a
    serializing instruction) anyway?
    A: No, now stop_machine uses per-cpu workqueue, so that handler will be
    executed from worker threads. There is no iret anymore.

    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    LKML-Reference: <20110303160137.GB1590@Krystal>
    Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Arjan van de Ven <arjan@infradead.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

    ---
    arch/x86/kernel/alternative.c | 7 ++++++-
    1 file changed, 6 insertions(+), 1 deletion(-)

    --- a/arch/x86/kernel/alternative.c
    +++ b/arch/x86/kernel/alternative.c
    @@ -620,7 +620,12 @@ static int __kprobes stop_machine_text_p
    flush_icache_range((unsigned long)p->addr,
    (unsigned long)p->addr + p->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;
    }




    \
     
     \ /
      Last update: 2011-03-22 00:35    [W:4.114 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site