summaryrefslogtreecommitdiffstats
path: root/Documentation/locking
diff options
context:
space:
mode:
authorPaul E. McKenney2015-09-21 06:01:22 +0200
committerPaul E. McKenney2015-09-21 06:01:22 +0200
commit19a5ecde086a6a5287978b12ae948fa691b197b7 (patch)
treedea41c8c9a9f6f0978b663090c382a2f23d4f189 /Documentation/locking
parentrcu: Change _wait_rcu_gp() to work around GCC bug 67055 (diff)
downloadkernel-qcow2-linux-19a5ecde086a6a5287978b12ae948fa691b197b7.tar.gz
kernel-qcow2-linux-19a5ecde086a6a5287978b12ae948fa691b197b7.tar.xz
kernel-qcow2-linux-19a5ecde086a6a5287978b12ae948fa691b197b7.zip
rcu: Suppress lockdep false positive for rcp->exp_funnel_mutex
In kernels built with CONFIG_PREEMPT=y, synchronize_rcu_expedited() invokes synchronize_sched_expedited() while holding RCU-preempt's root rcu_node structure's ->exp_funnel_mutex, which is acquired after the rcu_data structure's ->exp_funnel_mutex. The first thing that synchronize_sched_expedited() will do is acquire RCU-sched's rcu_data structure's ->exp_funnel_mutex. There is no danger of an actual deadlock because the locking order is always from RCU-preempt's expedited mutexes to those of RCU-sched. Unfortunately, lockdep considers both rcu_data structures' ->exp_funnel_mutex to be in the same lock class and therefore reports a deadlock cycle. This commit silences this false positive by placing RCU-sched's rcu_data structures' ->exp_funnel_mutex locks into their own lock class. Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'Documentation/locking')
0 files changed, 0 insertions, 0 deletions