RCU boosting and lockdep are not playing nice

[Sebastian Andrzej Siewior]

Once RCU-boosting kicks in I see this:

|=====================================
|WARNING: bad unlock balance detected!
|4.13.0-rc5+ #102 Not tainted
|-------------------------------------
|hackbench/1127 is trying to release lock (rcu_preempt_state) at:
|[<ffffffff810f1310>] rcu_read_unlock_special+0x330/0x340
|but there are no more locks to release!
|
|other info that might help us debug this:
|1 lock held by hackbench/1127:
| #0:  (rcu_read_lock){......}, at: [<ffffffff81202de5>] memcg_kmem_get_cache+0x95/0x270
|
|stack backtrace:
|CPU: 0 PID: 1127 Comm: hackbench Not tainted 4.13.0-rc5+ #102
|Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1 04/01/2014
|Call Trace:
| dump_stack+0x8e/0xcd
| ? rcu_read_unlock_special+0x330/0x340
| print_unlock_imbalance_bug+0xd8/0xe0
| lock_release+0x1db/0x440
| rt_mutex_unlock+0x2e/0xa0
| rcu_read_unlock_special+0x330/0x340
| __rcu_read_unlock+0x6f/0x80
| memcg_kmem_get_cache+0x17d/0x270

This pops up since cde50a67397c ("locking/rtmutex: Don't initialize lockdep
when not required"). Before that I had "DEBUG_LOCKS_WARN_ON(!name)"
trigger from rt_mutex_init_proxy_locked().

>From tracing it looks like this is the first boosting that happens and
the warning seems valid from lockdep's point of view. In
rt_mutex_init_proxy_locked() we assign a lock owner and we don't tell
lockdep about it - so it thinks that it is unlocked. The unlock in
rcu_read_unlock_special() is valid for the rtmutex code but lockdep
thinks it is unlocked and complains.

So what do we do here? Do we exclude the lock from lockdep or do we try
to teach lockdep what rt_mutex_init_proxy_locked() is really doing?

Sebastian