linux-kernel - [PATCH v2 2/2] debugobjects: Disable lockdep tracking of debugobjects internal locks

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Sep 2018 10:41:09 -0400
From:   Waiman Long <longman@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will.deacon@....com>
Cc:     linux-kernel@...r.kernel.org,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Arnd Bergmann <arnd@...db.de>, chuhu@...hat.com,
        Waiman Long <longman@...hat.com>
Subject: [PATCH v2 2/2] debugobjects: Disable lockdep tracking of debugobjects internal locks

It was discovered that running the ltp openposix_testsuite sigqueue-09-1
test on a certain 8-sock IvyBridge system caused it to have a hard lockup
with a full debug kernel.

 [89981.861500] NMI watchdog: Watchdog detected hard LOCKUP on cpu 17
   :
 [89981.939812] irq event stamp: 1166122
 [89981.943799] hardirqs last  enabled at (1166121): [<ffffffffb1048342>] kprobe_ftrace_handler+0x52/0x170
 [89981.954215] hardirqs last disabled at (1166122): [<ffffffffb08a3725>] tasklist_write_lock_irq+0x15/0x50
   :
 [89982.103134]  [<ffffffffb093a399>] lock_acquire+0x99/0x1e0
 [89982.109163]  [<ffffffffb0c0d19b>] ? debug_check_no_obj_freed+0xfb/0x270
 [89982.116562]  [<ffffffffb1042e1e>] _raw_spin_lock_irqsave+0x5e/0xa0
 [89982.123470]  [<ffffffffb0c0d19b>] ? debug_check_no_obj_freed+0xfb/0x270
 [89982.130851]  [<ffffffffb0c0d19b>] debug_check_no_obj_freed+0xfb/0x270
 [89982.138045]  [<ffffffffb08bf9f3>] ? __sigqueue_free.part.11+0x33/0x40
 [89982.145239]  [<ffffffffb0a6868a>] kmem_cache_free+0xca/0x390
 [89982.151553]  [<ffffffffb08bf9f3>] __sigqueue_free.part.11+0x33/0x40
 [89982.158552]  [<ffffffffb08c07b0>] flush_sigqueue+0x50/0x60
 [89982.164673]  [<ffffffffb08ad102>] release_task+0x3e2/0x6d0
   :

IRQ was disabled by the tasklist_write_lock_irq() call in
release_task(). The lockup is probably caused by the debug code running
for too long. We certainly want the debug code to verify the correctness
of the production code. However, there isn't too much value for one
piece of the debug code to verify the correctness of another piece of
debug code. In this particular case, the lockdep code is verifying the
correctness of the raw debug bucket lock within the debugobjects code.

The use of spin locks in the debugobjects code for synchronization is
pretty standard and looks to be correct to me.  This patch disables
the checking of the debugobjects internal locks by lockdep. In fact,
with this change, the hard lockup was not observed anymore.

Signed-off-by: Waiman Long <longman@...hat.com>
---
 lib/debugobjects.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 70935ed91125..68d72ed9ca22 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -1106,8 +1106,15 @@ void __init debug_objects_early_init(void)
 {
 	int i;
 
-	for (i = 0; i < ODEBUG_HASH_SIZE; i++)
+	/*
+	 * We don't need lockdep to verify correctness of debugobjects
+	 * internal locks.
+	 */
+	lockdep_set_novalidate_class(&pool_lock);
+	for (i = 0; i < ODEBUG_HASH_SIZE; i++) {
 		raw_spin_lock_init(&obj_hash[i].lock);
+		lockdep_set_novalidate_class(&obj_hash[i].lock);
+	}
 
 	for (i = 0; i < ODEBUG_POOL_SIZE; i++)
 		hlist_add_head(&obj_static_pool[i].node, &obj_pool);
-- 
2.18.0