From: Steven Rostedt <rostedt@goodmis.org>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
josh@joshtriplett.org, LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [RFC PATCH] rcu: don't ignore preempt_disable() in the idle loop
Date: Wed, 10 Mar 2010 08:51:53 -0500 [thread overview]
Message-ID: <1268229113.4471.678.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <4B96EE8A.5050003@cn.fujitsu.com>
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
next prev parent reply other threads:[~2010-03-10 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-09 11:13 Lai Jiangshan
2010-03-09 12:52 ` Steven Rostedt
2010-03-10 0:57 ` Lai Jiangshan
2010-03-10 13:51 ` Steven Rostedt [this message]
2010-03-10 0:54 ` Frederic Weisbecker
2010-03-10 1:30 ` Paul E. McKenney
2010-03-10 2:13 ` Lai Jiangshan
2010-03-10 2:28 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1268229113.4471.678.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®