Merge tag 'trace-fixes-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git...
authorLinus Torvalds <torvalds@linux-foundation.org>
Sat, 15 Feb 2014 23:03:34 +0000 (15:03 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sat, 15 Feb 2014 23:03:34 +0000 (15:03 -0800)
commit9bd01b9bbdc0aedcc49a6d974a0f30c0a9367f9e
tree3481708e608e2a36831b1f8eb73e36e6f1b43ce0
parent7fc9280462097f04ff15bff424106c601f8c270d
parent87fbb2ac6073a7039303517546a76074feb14c84
Merge tag 'trace-fixes-v3.14-rc2' of git://git./linux/kernel/git/rostedt/linux-trace

Pull twi tracing fixes from Steven Rostedt:
 "Two urgent 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 severe enough to have it fixed ASAP"

* tag 'trace-fixes-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace/x86: Use breakpoints for converting function graph caller
  ring-buffer: Fix first commit on sub-buffer having non-zero delta