[URGENT] trace-cmd: Fix for all stable versions for up coming fixin Linux v3.10

[Steven Rostedt]

I recently fixed a long standing bug in the splice code for ftrace. This
was something that I wanted fixed so that trace-cmd would work better.
The fix is to finally have the splice system call block until data is
available, instead of having trace-cmd poll reading the trace_pipe_raw
data file.

This fix is queued to go in to mainline for v3.10. Unfortunately, even
though I've wanted this for trace-cmd since day one, my trace-cmd
implementation to use this had a bug in it, that the kernel fix now
triggers. Basically, when tracing is finished (when the command that is
being recorded is done), trace-cmd stops tracing, signals the recording
threads to finish and then waits for the recording threads to exit.

Well, there's a race where the recording threads may make one last read
of the splice system call. The problem is that this read is blocking.
Now that tracing has been disabled by the main thread, this read will
block indefinitely as there is no more data to read. The main thread
waiting for the recorder threads to finish will continue to wait.
Hitting Ctrl-C kicks it and the threads all finish, but that's not what
should happen. The threads should finish when tracing is done, and not
require input from the user.

The fix is quite simple, and has been included in the latest trace-cmd
repo. I back ported the fix to the following versions, and tested all of
them running on a kernel with the splice fix. Without this update, all
the versions can end up blocked on splice and require user input to
continue. With the fix, they all work fine.

Here's the new stable trace-cmd versions that contain the fix:

  v1.0.7
  v1.1.2
  v1.2.3
  v2.0.3
  v2.1.1

and the main repo has it as well.

-- Steve