[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1398652660-4560-2-git-send-email-shan.hai@windriver.com>
Date: Mon, 28 Apr 2014 10:37:40 +0800
From: Shan Hai <shan.hai@...driver.com>
To: <rostedt@...dmis.org>, <fweisbec@...il.com>, <mingo@...hat.com>
CC: <linux-kernel@...r.kernel.org>
Subject: [PATCH 1/1] ftrace/ring_buffer: reset reader page after consuming read was performed to the page
Reset the reader page to avoid reading old trace entries repeatedly
in non-consuming read after a force stopped(by signal) consuming read.
The force stopped reader might left the reader page half filled by the
writer while the commit and tail pages are on the page when it is stopped.
The reader page holds the old trace entries until next consuming reader
swaps the page into ring buffer because the reader page is not part of
ring buffer. The non-consuming reader gets the old data repeatedly because
the reading of ring buffer starts from reader page and the reader would not
swap the reader page into ring buffer for its non-consuming nature.
The issue can be reproduced as below:
echo 0 > tracing_on
echo function > current_tracer
echo 1 > tracing_on
1, read the trace file as normal
cat trace | head -n 20
...
cat trace | head -n 20
The trace entries are changing at the head of the output.
NOTE:
If it's not changing at the start please repeat the reading
several times because the tracer need time to fill up the
whole buffer.
2, read the trace file after stopping 'cat trace_pipe' by Ctrl-C
cat trace_pipe
Ctrl-C
cat trace | head -n 200
...
cat trace | head -n 200
The trace entries at the head of the output stop changing,
followed by changing trace entries.
NOTE:
Please carefully check the time stamps of the trace entries,
the time stamps of some of them at the head stop changing
in the consecutive read.
The results of test 1 and 2 are not consistent with respect to the
updating of trace buffers, some part of the trace buffers are
not updated in the test 2 while all of them are updated in the
test 1.
And the result of test 1 is correct because the trace entries
supposed to be changed for the reason the tracer works under
overwrite mode by default.
Cc: stable@...r.kernel.org
Signed-off-by: Shan Hai <shan.hai@...driver.com>
---
kernel/trace/ring_buffer.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index c634868..76cf402 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3364,6 +3364,14 @@ static void rb_iter_reset(struct ring_buffer_iter *iter)
return;
iter->head = iter->head_page->read;
} else {
+ /* Reset the pointers because a force stopped(by signal)
+ * consuming reader might left the page half filled.
+ */
+ local_set(&cpu_buffer->reader_page->write, 0);
+ local_set(&cpu_buffer->reader_page->entries, 0);
+ local_set(&cpu_buffer->reader_page->page->commit, 0);
+ cpu_buffer->reader_page->read = 0;
+
iter->head_page = cpu_buffer->reader_page;
iter->head = cpu_buffer->reader_page->read;
}
--
1.8.5.2.233.g932f7e4
--
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