From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Alfredo Alvarez Fernandez <alfredoalvarezfernandez@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Sedat Dilek <sedat.dilek@gmail.com>,
Theodore Ts'o <tytso@mit.edu>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260
Date: Wed, 30 Mar 2016 11:36:59 +0200 [thread overview]
Message-ID: <20160330093659.GS3408@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160329084701.GA9393@gmail.com>
On Tue, Mar 29, 2016 at 10:47:02AM +0200, Ingo Molnar wrote:
> > You are right; this is lockdep running into a hash collision; which is a new
> > DEBUG_LOCKDEP test. See 9e4e7554e755 ("locking/lockdep: Detect chain_key
> > collisions").
>
> I've Cc:-ed Alfredo Alvarez Fernandez who added that test.
OK, so while the code in check_no_collision() seems sensible, it relies
on borken bits.
The whole chain_hlocks and /proc/lockdep_chains stuff appears to have
been buggered from the start.
The below patch should fix this.
Furthermore, our hash function has definite room for improvement.
---
include/linux/lockdep.h | 8 +++++---
kernel/locking/lockdep.c | 30 ++++++++++++++++++++++++------
kernel/locking/lockdep_proc.c | 2 ++
3 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index d026b190c530..2568c120513b 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -196,9 +196,11 @@ struct lock_list {
* We record lock dependency chains, so that we can cache them:
*/
struct lock_chain {
- u8 irq_context;
- u8 depth;
- u16 base;
+ /* see BUILD_BUG_ON()s in lookup_chain_cache() */
+ unsigned int irq_context : 2,
+ depth : 6,
+ base : 24;
+ /* 4 byte hole */
struct hlist_node entry;
u64 chain_key;
};
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 53ab2f85d77e..91a4b7780afb 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2099,15 +2099,37 @@ static inline int lookup_chain_cache(struct task_struct *curr,
chain->irq_context = hlock->irq_context;
i = get_first_held_lock(curr, hlock);
chain->depth = curr->lockdep_depth + 1 - i;
+
+ BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks));
+ BUILD_BUG_ON((1UL << 6) <= ARRAY_SIZE(curr->held_locks));
+ BUILD_BUG_ON((1UL << 8*sizeof(chain_hlocks[0])) <= ARRAY_SIZE(lock_classes));
+
if (likely(nr_chain_hlocks + chain->depth <= MAX_LOCKDEP_CHAIN_HLOCKS)) {
chain->base = nr_chain_hlocks;
- nr_chain_hlocks += chain->depth;
for (j = 0; j < chain->depth - 1; j++, i++) {
int lock_id = curr->held_locks[i].class_idx - 1;
chain_hlocks[chain->base + j] = lock_id;
}
chain_hlocks[chain->base + j] = class - lock_classes;
}
+
+ if (nr_chain_hlocks < MAX_LOCKDEP_CHAIN_HLOCKS)
+ nr_chain_hlocks += chain->depth;
+
+#ifdef CONFIG_DEBUG_LOCKDEP
+ /*
+ * Important for check_no_collision().
+ */
+ if (unlikely(nr_chain_hlocks > MAX_LOCKDEP_CHAIN_HLOCKS)) {
+ if (debug_locks_off_graph_unlock())
+ return 0;
+
+ print_lockdep_off("BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!");
+ dump_stack();
+ return 0;
+ }
+#endif
+
hlist_add_head_rcu(&chain->entry, hash_head);
debug_atomic_inc(chain_lookup_misses);
inc_chains();
@@ -2860,11 +2882,6 @@ static int separate_irq_context(struct task_struct *curr,
{
unsigned int depth = curr->lockdep_depth;
- /*
- * Keep track of points where we cross into an interrupt context:
- */
- hlock->irq_context = 2*(curr->hardirq_context ? 1 : 0) +
- curr->softirq_context;
if (depth) {
struct held_lock *prev_hlock;
@@ -3164,6 +3181,7 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
hlock->acquire_ip = ip;
hlock->instance = lock;
hlock->nest_lock = nest_lock;
+ hlock->irq_context = 2*(!!curr->hardirq_context) + !!curr->softirq_context;
hlock->trylock = trylock;
hlock->read = read;
hlock->check = check;
diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
index dbb61a302548..a0f61effad25 100644
--- a/kernel/locking/lockdep_proc.c
+++ b/kernel/locking/lockdep_proc.c
@@ -141,6 +141,8 @@ static int lc_show(struct seq_file *m, void *v)
int i;
if (v == SEQ_START_TOKEN) {
+ if (nr_chain_hlocks > MAX_LOCKDEP_CHAIN_HLOCKS)
+ seq_printf(m, "(buggered) ");
seq_printf(m, "all lock chains:\n");
return 0;
}
next prev parent reply other threads:[~2016-03-30 9:36 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-27 8:15 [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260 Sedat Dilek
2016-03-27 8:57 ` Sedat Dilek
2016-03-27 12:03 ` Linus Torvalds
2016-03-27 13:32 ` Boqun Feng
2016-03-27 18:23 ` Theodore Ts'o
2016-03-27 19:40 ` Sedat Dilek
[not found] ` <CA+55aFwoKRpgq8OCTxUaP+8gOg-mnN3nbruYgiK32a=C5U4TkQ@mail.gmail.com>
2016-03-27 20:24 ` Sedat Dilek
2016-03-27 20:48 ` Peter Zijlstra
2016-03-27 20:59 ` Sedat Dilek
2016-03-27 21:48 ` Sedat Dilek
2016-03-28 1:05 ` Boqun Feng
2016-03-28 6:33 ` Peter Zijlstra
2016-03-29 8:47 ` Ingo Molnar
2016-03-30 9:20 ` Sedat Dilek
2016-03-30 9:36 ` Sedat Dilek
2016-03-30 9:36 ` Peter Zijlstra [this message]
2016-03-30 9:49 ` Sedat Dilek
2016-03-30 10:33 ` Sedat Dilek
2016-03-30 12:43 ` Peter Zijlstra
2016-03-30 12:46 ` Sedat Dilek
2016-03-30 13:15 ` Peter Zijlstra
2016-03-30 9:50 ` Peter Zijlstra
2016-03-30 9:59 ` Boqun Feng
2016-03-30 10:36 ` Peter Zijlstra
2016-03-30 11:07 ` Sedat Dilek
2016-03-31 15:42 ` Peter Zijlstra
2016-03-31 15:52 ` Boqun Feng
2016-04-02 6:26 ` Sedat Dilek
2016-03-30 14:06 ` Peter Zijlstra
2016-03-30 15:21 ` Sedat Dilek
2016-03-30 17:03 ` [PATCH] lockdep: print chain_key collision information Alfredo Alvarez Fernandez
2016-03-30 17:19 ` Peter Zijlstra
2016-04-01 6:36 ` [tip:core/urgent] locking/lockdep: Print " tip-bot for Alfredo Alvarez Fernandez
2016-05-10 9:09 ` Peter Zijlstra
2016-04-04 15:31 ` [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260 Sedat Dilek
2016-04-04 16:02 ` Peter Zijlstra
2016-05-09 11:37 ` Sedat Dilek
2016-06-03 15:15 ` Sedat Dilek
2016-04-23 12:54 ` [tip:locking/urgent] lockdep: Fix lock_chain::base size tip-bot for Peter Zijlstra
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=20160330093659.GS3408@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alfredoalvarezfernandez@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.