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 acore serializing instruction such as "cpuid" should be executed on _each_ corebefore the new instruction is made visible.

Failure to do so can lead to unspecified behavior (Intel XMC erratas includeGeneral Protection Fault in the list), so we should avoid this at all cost.

This problem can affect modified code executed by interrupt handlers afterinterrupt are re-enabled at the end of stop_machine, because no core serializinginstruction is executed between the code modification and the moment interruptsare reenabled.

Because stop_machine_text_poke performs the text modification from the first CPUdecrementing stop_machine_first, modified code executed in thread context isalso affected by this problem. To explain why, we have to split the CPUs in twocategories: the CPU that initiates the text modification (calls text_poke_smp)and all the others. The scheduler, executed on all other CPUs afterstop_machine, issues an "iret" core serializing instruction, and thereforehandles core serialization for all these CPUs. However, the text modificationinitiator can continue its execution on the same thread and access the modifiedtext without any scheduler call. Given that the CPU that initiates the codemodification is not guaranteed to be the one actually performing the codemodification, 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.