From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, laijs@cn.fujitsu.com,
dipankar@in.ibm.com, akpm@linux-foundation.org,
mathieu.desnoyers@polymtl.ca, josh@joshtriplett.org,
dvhltc@us.ibm.com, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com
Subject: lockdep rcu-preempt and synchronize_srcu() awareness
Date: Mon, 8 Feb 2010 14:18:58 -0500 [thread overview]
Message-ID: <20100208191858.GA16288@Krystal> (raw)
Hi,
I just though about the following deadlock scenario involving rcu preempt and
mutexes. I see that lockdep does not warn about it, and it actually triggers a
deadlock on my box. It might be worth addressing for TREE_PREEMPT_RCU configs.
CPU A:
mutex_lock(&test_mutex);
synchronize_rcu();
mutex_unlock(&test_mutex);
CPU B:
rcu_read_lock();
mutex_lock(&test_mutex);
mutex_unlock(&test_mutex);
rcu_read_unlock();
But given that it's not legit to take a mutex from within a rcu read lock in
non-preemptible configs, I guess it's not much of a real-life problem, but I
think SRCU is also affected, because there is no lockdep annotation around
synchronize_srcu().
So I think it would be good to mark rcu_read_lock/unlock as not permitting
"might_sleep()" in non preemptable RCU configs, and having a look at lockdep
SRCU support might be worthwhile.
The following test module triggers the problem:
/* test-rcu-lockdep.c
*
* Test RCU-awareness of lockdep. Don't look at the interface, it's aweful.
* run, in parallel:
*
* cat /proc/testa
* cat /proc/testb
*/
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/proc_fs.h>
#include <linux/sched.h>
#include <linux/delay.h>
struct proc_dir_entry *pentrya = NULL;
struct proc_dir_entry *pentryb = NULL;
static DEFINE_MUTEX(test_mutex);
static int my_opena(struct inode *inode, struct file *file)
{
mutex_lock(&test_mutex);
synchronize_rcu();
mutex_unlock(&test_mutex);
return -EPERM;
}
static struct file_operations my_operationsa = {
.open = my_opena,
};
static int my_openb(struct inode *inode, struct file *file)
{
rcu_read_lock();
mutex_lock(&test_mutex);
ssleep(1);
mutex_unlock(&test_mutex);
rcu_read_unlock();
return -EPERM;
}
static struct file_operations my_operationsb = {
.open = my_openb,
};
int init_module(void)
{
pentrya = create_proc_entry("testa", 0444, NULL);
if (pentrya)
pentrya->proc_fops = &my_operationsa;
pentryb = create_proc_entry("testb", 0444, NULL);
if (pentryb)
pentryb->proc_fops = &my_operationsb;
return 0;
}
void cleanup_module(void)
{
remove_proc_entry("testa", NULL);
remove_proc_entry("testb", NULL);
}
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mathieu Desnoyers");
MODULE_DESCRIPTION("lockdep rcu test");
Thanks,
Mathieu
next reply other threads:[~2010-02-08 19:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-08 19:18 Mathieu Desnoyers [this message]
2010-02-08 19:41 ` lockdep rcu-preempt and synchronize_srcu() awareness Peter Zijlstra
2010-02-08 21:17 ` Paul E. McKenney
2010-02-08 21:57 ` Mathieu Desnoyers
2010-02-08 23: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=20100208191858.GA16288@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=niv@us.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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.