[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1301405984.2250.402.camel@laptop>
Date: Tue, 29 Mar 2011 15:39:44 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: rostedt@...dmis.org, mingo@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC] seqlock,lockdep: Add lock primitives to read_seqbegin().
On Tue, 2011-03-29 at 13:30 +0900, Tetsuo Handa wrote:
> static int locktest_open1(struct inode *inode, struct file *file)
> {
> write_seqlock(&seqlock1);
> msleep(1000); /* Open /proc/locktest2 while sleeping here. */
> br_read_lock(brlock1);
> br_read_unlock(brlock1);
> write_sequnlock(&seqlock1);
> return -EINVAL;
> }
>
> static int locktest_open2(struct inode *inode, struct file *file)
> {
> br_write_lock(brlock1);
> read_seqbegin2(&seqlock1);
> br_write_unlock(brlock1);
> return -EINVAL;
> }
>
> static int locktest_open3(struct inode *inode, struct file *file)
> {
> static DEFINE_MUTEX(mutex1);
> mutex_lock(&mutex1);
> locktest_open1(inode, file);
> mutex_unlock(&mutex1);
> return -EINVAL;
> }
That's quite horrid as far as test-cases go, why bother with the
userspace part at all?
In order to hit your inversion you need to do something like:
cat /proc/locktest1 & cat /proc/locktest2
if you do them serialized you'll never hit that inversion.
That said, there are some out-standing issues with rw_locks and lockdep,
Gautham and I worked on that for a while but we never persevered and
finished it..
http://lkml.org/lkml/2009/5/11/203
And I think you're hitting that case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists