From: Waiman Long <longman@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>
Cc: linux-kernel@vger.kernel.org,
Yang Shi <yang.shi@linux.alibaba.com>,
Arnd Bergmann <arnd@arndb.de>,
chuhu@redhat.com, Waiman Long <longman@redhat.com>
Subject: [PATCH v2 2/2] debugobjects: Disable lockdep tracking of debugobjects internal locks
Date: Tue, 25 Sep 2018 10:41:09 -0400 [thread overview]
Message-ID: <1537886469-18227-3-git-send-email-longman@redhat.com> (raw)
In-Reply-To: <1537886469-18227-1-git-send-email-longman@redhat.com>
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@redhat.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
next prev parent reply other threads:[~2018-09-25 14:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 14:41 [PATCH v2 0/2] debugobjects: Fix potential hard lockup by disabling lockdep Waiman Long
2018-09-25 14:41 ` [PATCH v2 1/2] locking/lockdep: Don't warn class/lock name mismatch for novalidate class Waiman Long
2018-09-25 14:41 ` Waiman Long [this message]
2018-09-25 15:32 ` [PATCH v2 2/2] debugobjects: Disable lockdep tracking of debugobjects internal locks Peter Zijlstra
2018-09-25 16:20 ` Waiman Long
2018-09-25 16:31 ` Peter Zijlstra
2018-09-25 16:36 ` Waiman Long
2018-09-28 18:33 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1537886469-18227-3-git-send-email-longman@redhat.com \
--to=longman@redhat.com \
--cc=arnd@arndb.de \
--cc=chuhu@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=yang.shi@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®