[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86195df9-2a43-2a0f-38ac-68792edc41c0@fb.com>
Date: Mon, 30 Jan 2017 14:30:45 -0700
From: Jens Axboe <axboe@...com>
To: "J. R. Okajima" <hooanon05g@...il.com>, <peterz@...radead.org>
CC: <linux-kernel@...r.kernel.org>, <darrick.wong@...cle.com>,
<david@...morbit.com>
Subject: Re: Q: lockdep_assert_held_read() after downgrade_write()
On 01/30/2017 02:25 PM, J. R. Okajima wrote:
> Peter Zijlstra,
>
> May I ask you a question?
> v4.10-rc1 got a commit
> f831948 2016-11-30 locking/lockdep: Provide a type check for lock_is_held
> I've tested a little and lockdep splat a stack trace.
>
> {
> DECLARE_RWSEM(rw);
> static struct lock_class_key key;
> lockdep_set_class(&rw, &key);
>
> down_read(&rw);
> lockdep_assert_held_read(&rw);
> up_read(&rw);
>
> down_write(&rw);
> lockdep_assert_held_exclusive(&rw);
> up_write(&rw);
>
> downgrade_write(&rw);
> lockdep_assert_held_read(&rw); <-- here
> up_read(&rw);
> }
>
> I was expecting that lockdep_assert_held_read() splat nothing after
> downgrade_write(). Is this warning an intentional behaviour?
>
> Also the final up_read() gives me a warning too. It is produced at
> lockdep.c:3514:lock_release(): DEBUG_LOCKS_WARN_ON(depth <= 0)
I don't think you understand how it works. downgrade_write() turns a write
lock into read held. To make that last sequence valid, you'd need:
down_write(&rw);
downgrade_write(&rw);
lockdep_assert_held_read(&rw)
up_read(&rw);
or just not drop up_write() from the last section.
--
Jens Axboe
Powered by blists - more mailing lists