summaryrefslogtreecommitdiffstats
path: root/arch/xtensa/kernel/entry.S
diff options
context:
space:
mode:
authorSteven Rostedt <srostedt@redhat.com>2012-05-30 13:36:38 -0400
committerSteven Rostedt <rostedt@goodmis.org>2012-05-31 23:12:19 -0400
commit8a4d0a687a599f39b7df3fe15f2d51d2157caf44 (patch)
tree0a110234b8109154a0ffbe9bc4eb0d545da85102 /arch/xtensa/kernel/entry.S
parenta192cd0413b71c2a3e4e48dd365af704be72b748 (diff)
ftrace: Use breakpoint method to update ftrace caller
On boot up and module load, it is fine to modify the code directly, without the use of breakpoints. This is because boot up modification is done before SMP is initialized, thus the modification is serial, and module load is done before the module executes. But after that we must use a SMP safe method to modify running code. Otherwise, if we are running the function tracer and update its function (by starting off the stack tracer, or perf tracing) the change of the function called by the ftrace trampoline is done directly. If this is being executed on another CPU, that CPU may take a GPF and crash the kernel. The breakpoint method is used to change the nops at all the functions, but the change of the ftrace callback handler itself was still using a direct modification. If tracing was enabled and the function callback was changed then another CPU could fault if it was currently calling the original callback. This modification must use the breakpoint method too. Note, the direct method is still used for boot up and module load. Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Diffstat (limited to 'arch/xtensa/kernel/entry.S')
0 files changed, 0 insertions, 0 deletions