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