lkml.org 
[lkml]   [2017]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Q: lockdep_assert_held_read() after downgrade_write()
From
Date
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

\
 
 \ /
  Last update: 2017-01-30 23:02    [W:0.098 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site