<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3354" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=078504002-16102008>For the bug <A 
href="https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555">https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555</A></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=078504002-16102008></SPAN></FONT> </DIV>
<DIV><FONT><SPAN class=078504002-16102008><FONT face=Arial size=2>Here's a patch 
which has passed Intel's testing and with this patch that issue can't be 
reproduced again now. It looks to be a </FONT><FONT face=Arial 
size=2>work-around and with the .28 a fix for the root cause of the problem. 
</FONT></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=078504002-16102008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=078504002-16102008>Please apply 
this patch for Intrepid.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=078504002-16102008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=078504002-16102008>- 
Yingying</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>> Date: Wed, 15 Oct 2008 18:21:44 -0400 
(EDT)<BR>> From: Steven Rostedt <<A 
href="mailto:rostedt@goodmis.org">rostedt@goodmis.org</A>><BR>> To: LKML 
<<A 
href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</A>>, 
<A href="mailto:stable@kernel.org">stable@kernel.org</A><BR>> cc: Linus 
Torvalds <<A 
href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</A>>,<BR>>         
Andrew Morton <<A 
href="mailto:akpm@linux-foundation.org">akpm@linux-foundation.org</A>>,<BR>>         
Arjan van de Ven <<A 
href="mailto:arjan@infradead.org">arjan@infradead.org</A>>, <A 
href="mailto:gregkh@suse.de">gregkh@suse.de</A>,<BR>>         
<A href="mailto:jesse.brandeburg@intel.com">jesse.brandeburg@intel.com</A>, 
Thomas Gleixner <<A 
href="mailto:tglx@linutronix.de">tglx@linutronix.de</A>>,<BR>>         
Ingo Molnar <<A href="mailto:mingo@elte.hu">mingo@elte.hu</A>><BR>> 
Subject: [PATCH -stable] disable CONFIG_DYNAMIC_FTRACE due to possible 
memory<BR>>         corruption on 
module unload<BR>> <BR>> <BR>> While debugging the e1000e corruption 
bug with Intel, we discovered<BR>> today that the dynamic ftrace code in 
mainline is the likely source of<BR>> this bug.<BR>> <BR>> For the 
stable kernel we are providing the only viable fix patch: labeling<BR>> 
CONFIG_DYNAMIC_FTRACE as broken. (see the patch below)<BR>> <BR>> We will 
follow up with a backport patch that contains the fixes. But since<BR>> the 
fixes are not a one liner, the safest approach for now is to<BR>> disable the 
code in question.<BR>> <BR>> The cause of the bug is due to the way the 
current code in mainline<BR>> handles dynamic ftrace.  When dynamic 
ftrace is turned on, it also<BR>> turns on CONFIG_FTRACE which enables the 
-pg config in gcc that places<BR>> a call to mcount at every function call. 
With just CONFIG_FTRACE this<BR>> causes a noticeable overhead.  
CONFIG_DYNAMIC_FTRACE works to ease this<BR>> overhead by dynamically 
updating the mcount call sites into nops.<BR>> <BR>> The problem arises 
when we trace functions and modules are unloaded.<BR>> The first time a 
function is called, it will call mcount and the mcount<BR>> call will call 
ftrace_record_ip. This records the calling site and<BR>> stores it in a 
preallocated hash table. Later on a daemon will<BR>> wake up and call 
kstop_machine and convert any mcount callers into<BR>> nops.<BR>> <BR>> 
The evolution of this code first tried to do this without the 
kstop_machine<BR>> and used cmpxchg to update the callers as they were 
called. But I<BR>> was informed that this is dangerous to do on SMP machines 
if another<BR>> CPU is running that same code. The solution was to do this 
with<BR>> kstop_machine.<BR>> <BR>> We still used cmpxchg to test if 
the code that we are modifying is<BR>> indeed code that we expect to be 
before updating it - as a final<BR>> line of defense.<BR>> <BR>> But on 
32bit machines, ioremapped memory and modules share the same<BR>> address 
space. When a module would load its code into memory and execute<BR>> some 
code, that would register the function.<BR>> <BR>> On module unload, 
ftrace incorrectly did not zap these functions from<BR>> its hash (this was 
the bug). The cmpxchg could have saved us in most<BR>> cases (via luck) - but 
with ioremap-ed memory that was exactly the wrong<BR>> thing to do - the 
results of cmpxchg on device memory are undefined.<BR>> (and will likely 
result in a write)<BR>> <BR>> The pending .28 ftrace tree does not have 
this bug anymore, as a general push<BR>> towards more robustness of code 
patching, this is done differently: we do not<BR>> use cmpxchg and we do a 
WARN_ON and turn the tracer off if anything deviates<BR>> from its expected 
state. Furthermore, patch sites are statically identified<BR>> during build 
time so there's no runtime discovery of dynamic code areas<BR>> anymore, and 
no room for code unmaps to cause the hash to become out of date.<BR>> 
<BR>> We believe the fragility of dynamic patching has been 
sufficiently<BR>> addressed in the development code via the static patching 
method, but further<BR>> suggestions to make it more robust are 
welcome.<BR>> <BR>> Signed-off-by: Steven Rostedt <<A 
href="mailto:srostedt@goodmis.org">srostedt@goodmis.org</A>><BR>> 
Acked-by: Ingo Molnar <<A 
href="mailto:mingo@elte.hu">mingo@elte.hu</A>><BR>> Acked-by: Thomas 
Gleixner <<A 
href="mailto:tglx@linutronix.de">tglx@linutronix.de</A>><BR>> 
---<BR>>  kernel/trace/Kconfig |    3 ++-<BR>>  1 
file changed, 2 insertions(+), 1 deletion(-)<BR>> <BR>> Index: 
linux-compile.git/kernel/trace/Kconfig<BR>> 
===================================================================<BR>> --- 
linux-compile.git.orig/kernel/trace/Kconfig 2008-10-02 
10:18:49.000000000<BR>> -0400<BR>> +++ 
linux-compile.git/kernel/trace/Kconfig      2008-10-15 
17:29:34.000000000<BR>> -0400<BR>> @@ -103,7 +103,8 @@ config 
CONTEXT_SWITCH_TRACER<BR>>           
all switching of tasks.<BR>> <BR>>  config DYNAMIC_FTRACE<BR>> 
-       bool "enable/disable ftrace tracepoints 
dynamically"<BR>> +       bool "enable/disable 
ftrace tracepoints dynamically (BROKEN)"<BR>> 
+       depends on 
BROKEN<BR>>         depends on 
FTRACE<BR>>         depends on 
HAVE_DYNAMIC_FTRACE<BR>>         
default y<BR>> <BR>> --<BR>> To unsubscribe from this list: send the 
line "unsubscribe linux-kernel" in<BR>> the body of a message to <A 
href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</A><BR>> 
More majordomo info at  <A 
href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</A><BR>> 
Please read the FAQ at  <A 
href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</A><BR></DIV></FONT>
<DIV> </DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=en-us><FONT face="Comic Sans MS" size=2>Best 
Regards,</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Comic Sans MS" 
size=2>Yingying</FONT></SPAN> </P>
<DIV> </DIV></BODY></HTML>