lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ