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) As an additional information, I increased some lockdep constants. Do you think this is related? include/linux/lockdep.h +#define MAX_LOCKDEP_SUBCLASSES (8UL + 4) +#define MAX_LOCKDEP_KEYS_BITS (13 + 3) kernel/locking/lockdep_internals.h +#define MAX_LOCKDEP_ENTRIES (32768UL << 5) +#define MAX_LOCKDEP_CHAINS_BITS (16 + 5) +#define MAX_STACK_TRACE_ENTRIES (524288UL << 5) J. R. Okajima