[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1537886469-18227-3-git-send-email-longman@redhat.com>
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
Powered by blists - more mailing lists