linux-kernel - Re: [RFC PATCH] rcu: don't ignore preempt

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] [day] [month] [year] [list]

Date:	Wed, 10 Mar 2010 08:51:53 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	josh@...htriplett.org, LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC PATCH] rcu: don't ignore preempt_disable() in the idle
 loop

On Wed, 2010-03-10 at 08:57 +0800, Lai Jiangshan wrote:

> No, this can not fix the bug we found with the ring buffer code.
> I think the bug is not come from this issue or from RCU.

Looking at the stress test, I believe the bug is not at the ring buffer
layer, but the ftrace layer above it.

There are some restrictions that are suppose to be implemented with
various actions of the ring buffer.

1) When using the iterator (reading the non-consuming trace file), the
ring buffer is not to be modified.

2) Same is true with resize and reset. The buffer should not be modified
during these actions, but more importantly, they should not happen while
an iterator is active.

3) Ftrace uses two ring buffers (one to store max latencies), when a max
is hit it switches buffers. I'm thinking that there may be cases we are
starting an operation on one and finishing it on another.

I've already found a few cases that ftrace does not protect against the
above, with the operations that this stress test does.

The main issue I see is that it is switching the tracer (which resets)
and it is also resizing the buffer, while the trace file is being read.
This may cause the iterator to be pointing to false pages. I'm going see
if disabling resizing and switching tracers when the trace file is open
prevents the crash. If this does prevent the crashes, then I'll see if I
can make the iterator more robust, if not, then we will have to prevent
these actions while someone has the trace file opened.

Thanks,

-- Steve

--
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/