From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com,
eric.dumazet@gmail.com, darren@dvhart.com
Subject: Re: [PATCH RFC tip/core/rcu 11/12] rcu: fix race condition in synchronize_sched_expedited()
Date: Thu, 11 Nov 2010 04:31:46 -0800 [thread overview]
Message-ID: <20101111123146.GF3134@linux.vnet.ibm.com> (raw)
In-Reply-To: <4CDBB309.9020406@kernel.org>
On Thu, Nov 11, 2010 at 10:10:33AM +0100, Tejun Heo wrote:
> Hello, Paul, Lai.
>
> On 11/11/2010 05:20 AM, Paul E. McKenney wrote:
> > On Wed, Nov 10, 2010 at 04:56:32PM +0800, Lai Jiangshan wrote:
> >> On 11/09/2010 09:26 PM, Tejun Heo wrote:
> >>> Hello, Paul.
> >>>
> >>>
> >>> How about something like the following? It's slightly bigger but I
> >>> think it's a bit easier to understand. Thanks.
> >>
> >> Hello, Paul, Tejun,
> >>
> >> I think this approach is good and much better when several tasks
> >> call synchronize_sched_expedited() at the same time.
> >
> > I am becoming more comfortable with it as well. Tejun, what kind of
> > testing did you do? Lai, could you please run it on your systems?
>
> I just compile tested it (so no SOB). Please feel free to take it and
> shape it into a proper patch. Oh, I think we can drop both mb()'s at
> the top and bottom as both atomic_inc_return() and atomic_cmpxchg()
> imply full memory barrier.
Actually, the memory barriers are still one source of discomfort to me.
I am concerned about the path out of the function that skips the
atomic_cmpxchg(), which seem to happen if some concurrent invocation
advances the "done" counter past us before we get around to checking it.
I agree on the atomic_inc_return() upon entry to the function, though.
And this is going to need some serious testing either way. ;-)
Thanx, Paul
next prev parent reply other threads:[~2010-11-11 12:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-07 2:05 [PATCH RFC tip/core/rcu 0/12] preview of RCU patches for 2.6.38 Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 01/12] rcu: add priority-inversion testing to rcutorture Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 02/12] rcu: move TINY_RCU from softirq to kthread Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 03/12] rcu: priority boosting for TINY_PREEMPT_RCU Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 04/12] rcu: add tracing for TINY_RCU and TINY_PREEMPT_RCU Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 05/12] rcu: document TINY_RCU and TINY_PREEMPT_RCU tracing Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 06/12] rcu: Distinguish between boosting and boosted Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 07/12] rcu: get rid of obsolete "classic" names in TREE_RCU tracing Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 08/12] rcu,cleanup: move synchronize_sched_expedited() out of sched.c Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 09/12] rcu,cleanup: simplify the code when cpu is dying Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 10/12] rcu: update documentation/comments for Lai's adoption patch Paul E. McKenney
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 11/12] rcu: fix race condition in synchronize_sched_expedited() Paul E. McKenney
2010-11-09 13:26 ` Tejun Heo
2010-11-10 8:56 ` Lai Jiangshan
2010-11-11 4:20 ` Paul E. McKenney
2010-11-11 9:10 ` Tejun Heo
2010-11-11 12:31 ` Paul E. McKenney [this message]
2010-11-11 12:52 ` Tejun Heo
2010-11-07 2:05 ` [PATCH RFC tip/core/rcu 12/12] rcu: Make synchronize_srcu_expedited() fast if running readers 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=20101111123146.GF3134@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=eric.dumazet@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=niv@us.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.