summaryrefslogtreecommitdiffstats
path: root/include/sound
diff options
context:
space:
mode:
authorSteven Rostedt <rostedt@goodmis.org>2008-10-30 16:08:32 -0400
committerIngo Molnar <mingo@elte.hu>2008-10-30 21:30:08 +0100
commit17666f02b118099028522dfc3df00a235700e216 (patch)
tree6a7d280b9a6440cc7b8aab54d1e3e970d4ca00b2 /include/sound
parent7f82f000ed030d1108b4de47d9e2d556092980c6 (diff)
downloadop-kernel-dev-17666f02b118099028522dfc3df00a235700e216.zip
op-kernel-dev-17666f02b118099028522dfc3df00a235700e216.tar.gz
ftrace: nmi safe code modification
Impact: fix crashes that can occur in NMI handlers, if their code is modified Modifying code is something that needs special care. On SMP boxes, if code that is being modified is also being executed on another CPU, that CPU will have undefined results. The dynamic ftrace uses kstop_machine to make the system act like a uniprocessor system. But this does not address NMIs, that can still run on other CPUs. One approach to handle this is to make all code that are used by NMIs not be traced. But NMIs can call notifiers that spread throughout the kernel and this will be very hard to maintain, and the chance of missing a function is very high. The approach that this patch takes is to have the NMIs modify the code if the modification is taking place. The way this works is that just writing to code executing on another CPU is not harmful if what is written is the same as what exists. Two buffers are used: an IP buffer and a "code" buffer. The steps that the patcher takes are: 1) Put in the instruction pointer into the IP buffer and the new code into the "code" buffer. 2) Set a flag that says we are modifying code 3) Wait for any running NMIs to finish. 4) Write the code 5) clear the flag. 6) Wait for any running NMIs to finish. If an NMI is executed, it will also write the pending code. Multiple writes are OK, because what is being written is the same. Then the patcher must wait for all running NMIs to finish before going to the next line that must be patched. This is basically the RCU approach to code modification. Thanks to Ingo Molnar for suggesting the idea, and to Arjan van de Ven for his guidence on what is safe and what is not. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'include/sound')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud