Message-ID: <1362184337.1231.49.camel@gandalf.local.home>
Date:	Fri, 01 Mar 2013 19:32:17 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>,
	linux-trace-users <linux-trace-users@...r.kernel.org>
Cc:	John Kacur <jkacur@...il.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	ubuntu-motu@...ts.ubuntu.com,
	"Ying-Chun Liu (PaulLiu)" <paul.liu@...onical.com>,
	Neependra Kumar Khare <nkhare@...hat.com>,
	Mel Gorman <mgorman@...e.de>, David Sharp <dhsharp@...gle.com>
Subject: [URGENT] trace-cmd: Fix for all stable versions for up coming fix
 in Linux v3.10

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

>From 4b04db879a99d600988bc302e7ac88e8c012f98f Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Red Hat)" <rostedt@...dmis.org>
Date: Thu, 28 Feb 2013 11:29:43 -0500
Subject: [PATCH] trace-cmd: Do not block on reads when record is finished

Starting with Linux v3.10, trace_pipe_raw will block on reads.
We need to make sure that when the trace is done, the reads do
not block, and flushing finishes reading the ring buffer.

Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
---
 trace-recorder.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/trace-recorder.c b/trace-recorder.c
index 1b9723d..4e15b86 100644
--- a/trace-recorder.c
+++ b/trace-recorder.c
@@ -249,9 +249,15 @@ int tracecmd_start_recording(struct tracecmd_recorder *recorder, unsigned long s
 
 void tracecmd_stop_recording(struct tracecmd_recorder *recorder)
 {
+	long flags;
+
 	if (!recorder)
 		return;
 
+	/* Do not block on reads for flushing */
+	flags = fcntl(recorder->trace_fd, F_GETFL);
+	fcntl(recorder->trace_fd, F_SETFL, flags | O_NONBLOCK);
+
 	recorder->stop = 1;
 }
 
-- 
1.7.10.4



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists