diff options
author | Steven Rostedt <srostedt@redhat.com> | 2012-05-30 19:36:38 +0200 |
---|---|---|
committer | Steven Rostedt <rostedt@goodmis.org> | 2012-06-01 05:12:19 +0200 |
commit | 8a4d0a687a599f39b7df3fe15f2d51d2157caf44 (patch) | |
tree | 0a110234b8109154a0ffbe9bc4eb0d545da85102 /arch/mn10300 | |
parent | ftrace: Synchronize variable setting with breakpoints (diff) | |
download | linux-8a4d0a687a599f39b7df3fe15f2d51d2157caf44.tar.xz linux-8a4d0a687a599f39b7df3fe15f2d51d2157caf44.zip |
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/mn10300')
0 files changed, 0 insertions, 0 deletions