From: Dave Jones <davej@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: MAX_LOCKDEP_ENTRIES too low
Date: Tue, 23 Oct 2012 15:50:26 -0400 [thread overview]
Message-ID: <20121023195026.GA2872@redhat.com> (raw)
In-Reply-To: <1350650972.30157.34.camel@twins>
On Fri, Oct 19, 2012 at 02:49:32PM +0200, Peter Zijlstra wrote:
> > Not sure why this suddenly got a lot worse in 3.7
>
> Did we add a static array of structures with locks in somewhere? Doing
> that is a great way of blowing up the number of lock classes and the
> resulting amount of lock dependency chains.
So I hit it again, but didn't see anything that I hadn't seen already
in /proc/lockdep. I so tried doubling MAX_LOCKDEP_ENTRIES again.
A while later, I got this oops. I'm unsure now if this is a genuine bug,
or a side-effect of lockdep not working with such a large MAX_LOCKDEP_ENTRIES
opinions ?
BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
IP: [<ffffffff810e185e>] __lock_acquire+0x5e/0x1ba0
PGD 8e72c067 PUD 34f07067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: fuse nfnetlink ipt_ULOG binfmt_misc nfc caif_socket caif phonet can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 lockd sunrpc bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables kvm_intel kvm usb_debug crc32c_intel ghash_clmulni_intel microcode pcspkr i2c_i801 e1000e uinput i915 video i2c_algo_bit drm_kms_helper drm i2c_core
CPU 7
Pid: 27513, comm: trinity-child0 Not tainted 3.7.0-rc2+ #43 Intel Corporation 2012 Client Platform/Emerald Lake 2
RIP: 0010:[<ffffffff810e185e>] [<ffffffff810e185e>] __lock_acquire+0x5e/0x1ba0
RSP: 0018:ffff8800803f7b28 EFLAGS: 00010046
RAX: 0000000000000086 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000018
RBP: ffff8800803f7c18 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000000 R11: 2222222222222222 R12: 0000000000000002
R13: ffff880051dd8000 R14: 0000000000000002 R15: 0000000000000018
FS: 00007f9fc6ccb740(0000) GS:ffff880148a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000008e6fb000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process trinity-child0 (pid: 27513, threadinfo ffff8800803f6000, task ffff880051dd8000)
Stack:
ffff8800803f7b48 ffffffff816c5c59 ffff8800803f7b48 ffff88014840ebc0
ffff8800803f7b68 ffffffff816c18e3 ffff8800803f7d10 0000000000000001
ffff8800803f7ba8 ffffffff810a1e62 ffff8800803f7d10 0000000000000282
Call Trace:
[<ffffffff816c5c59>] ? sub_preempt_count+0x79/0xd0
[<ffffffff816c18e3>] ? _raw_spin_unlock_irqrestore+0x73/0xa0
[<ffffffff810a1e62>] ? hrtimer_try_to_cancel+0x52/0x210
[<ffffffff810eb9e5>] ? debug_rt_mutex_free_waiter+0x15/0x180
[<ffffffff816c0107>] ? rt_mutex_slowlock+0x127/0x1b0
[<ffffffff810b7039>] ? local_clock+0x89/0xa0
[<ffffffff810e3ac2>] lock_acquire+0xa2/0x220
[<ffffffff810e812c>] ? futex_lock_pi.isra.18+0x1cc/0x390
[<ffffffff816c09e0>] _raw_spin_lock+0x40/0x80
[<ffffffff810e812c>] ? futex_lock_pi.isra.18+0x1cc/0x390
[<ffffffff810e812c>] futex_lock_pi.isra.18+0x1cc/0x390
[<ffffffff810a1980>] ? update_rmtp+0x70/0x70
[<ffffffff810e99e4>] do_futex+0x394/0xa50
[<ffffffff8119ec43>] ? might_fault+0x53/0xb0
[<ffffffff810ea12d>] sys_futex+0x8d/0x190
[<ffffffff816ca288>] tracesys+0xe1/0xe6
Code: d8 45 0f 45 e0 4c 89 75 f0 4c 89 7d f8 85 c0 0f 84 f8 00 00 00 8b 05 22 fe f3 00 49 89 ff 89 f3 41 89 d2 85 c0 0f 84 02 01 00 00 <49> 8b 07 ba 01 00 00 00 48 3d c0 81 06 82 44 0f 44 e2 83 fb 01
RIP [<ffffffff810e185e>] __lock_acquire+0x5e/0x1ba0
RSP <ffff8800803f7b28>
CR2: 0000000000000018
next prev parent reply other threads:[~2012-10-23 19:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-18 1:53 MAX_LOCKDEP_ENTRIES too low (called from ioc_release_fn) Dave Jones
2012-10-18 5:53 ` Jens Axboe
2012-10-19 5:21 ` Dave Jones
2012-10-19 12:49 ` Peter Zijlstra
2012-10-19 19:29 ` Dave Jones
2012-10-23 19:50 ` Dave Jones [this message]
2012-10-24 20:24 ` pi futex oops in __lock_acquire Dave Jones
2012-10-25 4:44 ` Darren Hart
2012-10-25 11:09 ` Dave Jones
2012-11-20 16:46 ` Dave Jones
2012-11-20 17:27 ` Darren Hart
2012-11-20 23:10 ` Darren Hart
2012-11-21 0:30 ` Darren Hart
2012-11-21 17:37 ` Darren Hart
2012-11-21 17:46 ` Dave Jones
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=20121023195026.GA2872@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/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.