[PATCH 0/2] [GIT PULL] tracing: A couple more regression fixes

[PATCH 0/2] [GIT PULL] tracing: A couple more regression fixes

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]


Linus,

The clean up patch commit 0fb9656d "tracing: Make tracing_enabled be equal
to tracing_on" caused two regressions.

1) The irqs off latency tracer no longer starts if tracing_on is off
  when the tracer is set, and then tracing_on is enabled. The tracing_on
  file needs the hook that tracing_enabled had to enable tracers if they
  request it (call the tracer's start() method).

2) That commit had a separate change that really should have been a
  separate patch, but it must have been added accidently with the -a
  option of git commit. But as the change is still related to the commit
  it wasn't noticed in review. That change, changed the way blocking is
  done by the trace_pipe file with respect to the tracing_on settings.
  I've been told that this change breaks current userspace, and this
  specific change is being reverted.

Please pull trace-3.8-rc3-regression-fix, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-3.8-rc3-regression-fix

Head SHA1: 84c630600dc007d2fbd307088b87c9be85b40a97


Liu Bo (1):
      tracing: Fix regression of trace_pipe

Steven Rostedt (1):
      tracing: Fix regression with irqsoff tracer and tracing_on file

----
 kernel/trace/trace.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[PATCH 1/2] tracing: Fix regression with irqsoff tracer and tracing_on file

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

From: Steven Rostedt <srostedt@redhat.com>

Commit 02404baf1b47 "tracing: Remove deprecated tracing_enabled file"
removed the tracing_enabled file as it never worked properly and
the tracing_on file should be used instead. But the tracing_on file
didn't call into the tracers start/stop routines like the
tracing_enabled file did. This caused trace-cmd to break when it
enabled the irqsoff tracer.

If you just did "echo irqsoff > current_tracer" then it would work
properly. But the tool trace-cmd disables tracing first by writing
"0" into the tracing_on file. Then it writes "irqsoff" into
current_tracer and then writes "1" into tracing_on. Unfortunately,
the above commit changed the irqsoff tracer to check the tracing_on
status instead of the tracing_enabled status. If it's disabled then
it does not start the tracer internals.

The problem is that writing "1" into tracing_on does not call the
tracers "start" routine like writing "1" into tracing_enabled did.
This makes the irqsoff tracer not start when using the trace-cmd
tool, and is a regression for userspace.

Simple fix is to have the tracing_on file call the tracers start()
method when being enabled (and the stop() method when disabled).

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 1bbfa04..f3ec1cf 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4817,10 +4817,17 @@ rb_simple_write(struct file *filp, const char __user *ubuf,
 		return ret;
 
 	if (buffer) {
-		if (val)
+		mutex_lock(&trace_types_lock);
+		if (val) {
 			ring_buffer_record_on(buffer);
-		else
+			if (current_trace->start)
+				current_trace->start(tr);
+		} else {
 			ring_buffer_record_off(buffer);
+			if (current_trace->stop)
+				current_trace->stop(tr);
+		}
+		mutex_unlock(&trace_types_lock);
 	}
 
 	(*ppos)++;
-- 
1.7.10.4



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[PATCH 2/2] tracing: Fix regression of trace_pipe

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

From: Liu Bo <bo.li.liu@oracle.com>

Commit 0fb9656d "tracing: Make tracing_enabled be equal to tracing_on"
changes the behaviour of trace_pipe, ie. it makes trace_pipe return if
we've read something and tracing is enabled, and this means that we have
to 'cat trace_pipe' again and again while running tests.

IMO the right way is if tracing is enabled, we always block and wait for
ring buffer, or we may lose what we want since ring buffer's size is limited.

Link: http://lkml.kernel.org/r/1358132051-5410-1-git-send-email-bo.li.liu@oracle.com

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index f3ec1cf..3c13e46 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3454,7 +3454,7 @@ static int tracing_wait_pipe(struct file *filp)
 			return -EINTR;
 
 		/*
-		 * We block until we read something and tracing is enabled.
+		 * We block until we read something and tracing is disabled.
 		 * We still block if tracing is disabled, but we have never
 		 * read anything. This allows a user to cat this file, and
 		 * then enable tracing. But after we have read something,
@@ -3462,7 +3462,7 @@ static int tracing_wait_pipe(struct file *filp)
 		 *
 		 * iter->pos will be 0 if we haven't read anything.
 		 */
-		if (tracing_is_enabled() && iter->pos)
+		if (!tracing_is_enabled() && iter->pos)
 			break;
 	}
 
-- 
1.7.10.4



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]