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
