linux-kernel - RCU boosting and lockdep are not playing nice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 18 Aug 2017 22:04:26 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     tglx@...utronix.de, peterz@...radead.org
Cc:     mingo@...nel.org, paulmck@...ux.vnet.ibm.com,
        linux-kernel@...r.kernel.org, alexander.levin@...izon.com
Subject: RCU boosting and lockdep are not playing nice

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