aboutsummaryrefslogtreecommitdiff
path: root/kernel/stop_machine.c
diff options
context:
space:
mode:
authorLinus Torvalds2018-01-24 10:08:16 -0800
committerLinus Torvalds2018-01-24 10:08:16 -0800
commit03fae44b41062419aedcf2ae4ad68034f440f862 (patch)
tree5e5f2c73feb4e0e050ae7fc1d258092c9922090b /kernel/stop_machine.c
parentce30f264b33d9e3d27e34638976c52b578648b92 (diff)
parent2ee5b92a2598d9e403337185fdf88f661dee8616 (diff)
Merge tag 'trace-v4.15-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt: "With the new ORC unwinder, ftrace stack tracing became disfunctional. One was that ORC didn't know how to handle the ftrace callbacks in general (which Josh fixed). The other was that ORC would just bail if it hit a dynamically allocated trampoline. Which means all ftrace stack tracing that happens from the function tracer would produce no results (that includes killing the max stack size tracer). I added a check to the ORC unwinder to see if the trampoline belonged to ftrace, and if it did, use the orc entry of the static trampoline that was used to create the dynamic one (it would be identical). Finally, I noticed that the skip values of the stack tracing were out of whack. I went through and fixed them up" * tag 'trace-v4.15-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Update stack trace skipping for ORC unwinder ftrace, orc, x86: Handle ftrace dynamically allocated trampolines x86/ftrace: Fix ORC unwinding from ftrace handlers
Diffstat (limited to 'kernel/stop_machine.c')
0 files changed, 0 insertions, 0 deletions