From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Dipankar Sarma <dipankar@in.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: INFO: possible circular locking dependency detected
Date: Thu, 14 Jul 2011 12:18:09 -0700 [thread overview]
Message-ID: <20110714191809.GF2349@linux.vnet.ibm.com> (raw)
In-Reply-To: <1310665613.27864.50.camel@gandalf.stny.rr.com>
On Thu, Jul 14, 2011 at 01:46:53PM -0400, Steven Rostedt wrote:
> egad! Looking at this code more, there's nothing keeping
> t->rcu_read_unlock_special safe! If it can be modified by the kthread,
> and current, then we must use atomic operations or modify under lock.
> Otherwise the old read/modify/write can corrupt it.
>
> t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
>
> is done before the lock is taken in rcu_read_unlock_special. If the
> kthread is running rcu_boost() then its code:
>
> t->rcu_read_unlock_special |= RCU_READ_UNLOCK_BOOSTED;
>
> Can even negate the removing of the RCU_READ_UNLOCK_BLOCKED!
<red face>
Excellent catch, Steve, both this and your previous email. Really stupid
mistake on my part. :-(
I believe that this affects only TREE_PREEMPT_RCU kernels with RCU_BOOST
set: interrupt disabling takes care of TINY_PREEMPT_RCU. I think, anyway.
Please see below for a patch that I believe fixes this problem.
It relies on the fact that RCU_READ_UNLOCK_BOOSTED cannot be set unless
RCU_READ_UNLOCK_BLOCKED is also set, which allows the two to be in
separate variables. The original ->rcu_read_unlock_special is handled
only by the corresponding thread, while the new ->rcu_boosted is accessed
and updated only with the rcu_node structure's ->lock held.
Thoughts?
Thanx, Paul
------------------------------------------------------------------------
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 496770a..2a88747 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1254,6 +1254,9 @@ struct task_struct {
#ifdef CONFIG_PREEMPT_RCU
int rcu_read_lock_nesting;
char rcu_read_unlock_special;
+#ifdef CONFIG_RCU_BOOST
+ int rcu_boosted;
+#endif /* #ifdef CONFIG_RCU_BOOST */
struct list_head rcu_node_entry;
#endif /* #ifdef CONFIG_PREEMPT_RCU */
#ifdef CONFIG_TREE_PREEMPT_RCU
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 75113cb..8d38a98 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -342,6 +342,11 @@ static void rcu_read_unlock_special(struct task_struct *t)
#ifdef CONFIG_RCU_BOOST
if (&t->rcu_node_entry == rnp->boost_tasks)
rnp->boost_tasks = np;
+ /* Snapshot and clear ->rcu_boosted with rcu_node lock held. */
+ if (t->rcu_boosted) {
+ special |= RCU_READ_UNLOCK_BOOSTED;
+ t->rcu_boosted = 0;
+ }
#endif /* #ifdef CONFIG_RCU_BOOST */
t->rcu_blocked_node = NULL;
@@ -358,7 +363,6 @@ static void rcu_read_unlock_special(struct task_struct *t)
#ifdef CONFIG_RCU_BOOST
/* Unboost if we were boosted. */
if (special & RCU_READ_UNLOCK_BOOSTED) {
- t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BOOSTED;
rt_mutex_unlock(t->rcu_boost_mutex);
t->rcu_boost_mutex = NULL;
}
@@ -1174,7 +1178,7 @@ static int rcu_boost(struct rcu_node *rnp)
t = container_of(tb, struct task_struct, rcu_node_entry);
rt_mutex_init_proxy_locked(&mtx, t);
t->rcu_boost_mutex = &mtx;
- t->rcu_read_unlock_special |= RCU_READ_UNLOCK_BOOSTED;
+ t->rcu_boosted = 1;
raw_spin_unlock_irqrestore(&rnp->lock, flags);
rt_mutex_lock(&mtx); /* Side effect: boosts task t's priority. */
rt_mutex_unlock(&mtx); /* Keep lockdep happy. */
next prev parent reply other threads:[~2011-07-14 19:18 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-14 14:49 INFO: possible circular locking dependency detected Sergey Senozhatsky
2011-07-14 16:41 ` Peter Zijlstra
2011-07-14 16:57 ` Paul E. McKenney
2011-07-14 19:16 ` Sergey Senozhatsky
2011-07-14 19:15 ` Sergey Senozhatsky
2011-07-14 19:34 ` Paul E. McKenney
2011-07-14 19:38 ` Dave Jones
2011-07-14 20:33 ` Paul E. McKenney
2011-07-14 19:38 ` Sergey Senozhatsky
2011-07-14 16:58 ` Steven Rostedt
2011-07-14 17:02 ` Steven Rostedt
2011-07-14 17:05 ` Paul E. McKenney
2011-07-14 17:32 ` Steven Rostedt
2011-07-14 17:46 ` Steven Rostedt
2011-07-14 19:18 ` Paul E. McKenney [this message]
2011-07-14 19:41 ` Steven Rostedt
2011-07-14 20:33 ` Paul E. McKenney
2011-07-15 11:05 ` Ed Tomlinson
2011-07-15 11:29 ` Peter Zijlstra
2011-07-15 11:35 ` Ed Tomlinson
2011-07-15 11:39 ` Peter Zijlstra
2011-07-15 18:11 ` Paul E. McKenney
2011-07-15 12:42 ` Paul E. McKenney
2011-07-15 13:07 ` Peter Zijlstra
2011-07-15 14:36 ` Paul E. McKenney
2011-07-15 15:04 ` Peter Zijlstra
2011-07-15 15:59 ` Paul E. McKenney
2011-07-15 16:11 ` Peter Zijlstra
2011-07-15 16:56 ` Paul E. McKenney
2011-07-15 21:48 ` Ed Tomlinson
2011-07-15 22:04 ` Paul E. McKenney
2011-07-16 19:42 ` Ed Tomlinson
2011-07-17 0:02 ` Paul E. McKenney
2011-07-17 1:56 ` Ed Tomlinson
2011-07-17 14:28 ` Paul E. McKenney
2011-07-18 15:15 ` Paul E. McKenney
2011-07-18 9:29 ` Peter Zijlstra
2011-07-18 15:29 ` Paul E. McKenney
2011-07-15 16:55 ` Steven Rostedt
2011-07-15 17:03 ` Paul E. McKenney
2011-07-15 17:16 ` Steven Rostedt
2011-07-15 17:24 ` Paul E. McKenney
2011-07-15 17:42 ` Steven Rostedt
2011-07-15 18:33 ` Paul E. McKenney
-- strict thread matches above, loose matches on Subject: below --
2013-11-20 20:15 Alexei Starovoitov
2013-11-20 23:24 ` Casey Schaufler
2011-08-07 16:22 Justin P. Mattock
2011-08-11 20:57 ` Justin P. Mattock
2009-12-06 10:11 Richard Zidlicky
2009-10-10 23:09 John Kacur
2007-02-08 15:03 Pedro M. López
2006-10-16 14:05 alpha @ steudten Engineering
2006-10-16 14:32 ` Nick Piggin
2006-10-16 15:42 ` Randy Dunlap
2006-10-16 15:46 ` Nick Piggin
2006-10-19 6:02 ` Andrew Morton
2006-10-19 6:30 ` Nick Piggin
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=20110714191809.GF2349@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/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.