[lkml]   [2014]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH 0/2] [GIT PULL] tracing: Two urgent fixes


Two fixes in the tracing utility.

The first is a fix for the way the ring buffer stores timestamps.
After a restructure of the code was done, the ring buffer timestamp
logic missed the fact that the first event on a sub buffer is to have
a zero delta, as the full timestamp is stored on the sub buffer itself.
But because the delta was not cleared to zero, the timestamp for that
event will be calculated as the real timestamp + the delta from the
last timestamp. This can skew the timestamps of the events and
have them say they happened when they didn't really happen. That's bad.

The second fix is for modifying the function graph caller site.
When the stop machine was removed from updating the function tracing
code, it missed updating the function graph call site location.
It is still modified as if it is being done via stop machine. But it's not.
This can lead to a GPF and kernel crash if the function graph call site
happens to lie between cache lines and one CPU is executing it while
another CPU is doing the update. It would be a very hard condition to
hit, but the result is sever enough to have it fixed ASAP.

Please pull the latest trace-fixes-v3.14-rc2 tree, which can be found at:


Tag SHA1: 390f3e6a6f910b3aea1cef47b9339b99d7f3576f
Head SHA1: 87fbb2ac6073a7039303517546a76074feb14c84

Steven Rostedt (Red Hat) (2):
ring-buffer: Fix first commit on sub-buffer having non-zero delta
ftrace/x86: Use breakpoints for converting function graph caller

arch/x86/kernel/ftrace.c | 83 ++++++++++++++++++++++++++--------------------
kernel/trace/ring_buffer.c | 7 ++++
2 files changed, 54 insertions(+), 36 deletions(-)

 \ /
  Last update: 2014-02-15 15:01    [W:0.031 / U:15.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site