From: Sasha Levin <sasha.levin@oracle.com>
To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: lockdep: BUG: MAX_LOCKDEP_ENTRIES too low!
Date: Thu, 19 Dec 2013 00:53:56 -0500 [thread overview]
Message-ID: <52B289F4.7060205@oracle.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4136 bytes --]
Hi all,
I think that my bloated kernel managed to create way too many entries in the
dependency table. If that sounds right, I can send a patch to increase those.
Attached /proc/lock_stat as requested as well.
[ 1078.462898] BUG: MAX_LOCKDEP_ENTRIES too low!
[ 1078.462898] turning off the locking correctness validator.
[ 1078.463109] Please attach the output of /proc/lock_stat to the bug report
[ 1078.463968] CPU: 1 PID: 26372 Comm: trinity-child16 Tainted: G W 3.13.0-rc
4-next-20131218-sasha-00014-gf6be483-dirty #4160
[ 1078.463968] ffff8801bb9b8c10 ffff8801bb34d788 ffffffff8439598c ffff8801bb34d788
[ 1078.464297] ffff8801bb9b8bd8 ffff8801bb34d798 ffffffff8118e681 ffff8801bb34d838
[ 1078.465304] ffffffff81193a7a ffff8801bb34d7b8 00000000810b4214 ffff8800cc1d83c0
[ 1078.466442] Call Trace:
[ 1078.470111] [<ffffffff8439598c>] dump_stack+0x52/0x7f
[ 1078.470111] [<ffffffff8118e681>] T.1062+0x31/0xb0
[ 1078.470111] [<ffffffff81193a7a>] check_prev_add+0x4ba/0x550
[ 1078.470111] [<ffffffff810b4214>] ? kvm_clock_read+0x24/0x50
[ 1078.470121] [<ffffffff810b4214>] ? kvm_clock_read+0x24/0x50
[ 1078.470121] [<ffffffff811941d3>] validate_chain+0x6c3/0x7b0
[ 1078.470121] [<ffffffff81174d58>] ? sched_clock_cpu+0x108/0x120
[ 1078.470121] [<ffffffff8119476d>] __lock_acquire+0x4ad/0x580
[ 1078.470121] [<ffffffff811949c2>] lock_acquire+0x182/0x1d0
[ 1078.470121] [<ffffffff83fb67dc>] ? tcp_sendmsg+0x2c/0xd50
[ 1078.470121] [<ffffffff83e508aa>] lock_sock_nested+0x8a/0xa0
[ 1078.470121] [<ffffffff83fb67dc>] ? tcp_sendmsg+0x2c/0xd50
[ 1078.470121] [<ffffffff8107499d>] ? sched_clock+0x1d/0x30
[ 1078.470121] [<ffffffff83fb67dc>] tcp_sendmsg+0x2c/0xd50
[ 1078.470121] [<ffffffff81174d58>] ? sched_clock_cpu+0x108/0x120
[ 1078.470121] [<ffffffff8118dbca>] ? get_lock_stats+0x2a/0x60
[ 1078.470121] [<ffffffff8118dc0e>] ? put_lock_stats+0xe/0x30
[ 1078.470121] [<ffffffff83fe6ef8>] ? inet_sendmsg+0x178/0x1f0
[ 1078.470121] [<ffffffff81aba87a>] ? delay_tsc+0xfa/0x120
[ 1078.470121] [<ffffffff83fe6f53>] inet_sendmsg+0x1d3/0x1f0
[ 1078.470121] [<ffffffff83fe6d80>] ? inet_recvmsg+0x200/0x200
[ 1078.470121] [<ffffffff810b4214>] ? kvm_clock_read+0x24/0x50
[ 1078.470121] [<ffffffff83e4d620>] sock_sendmsg+0x90/0xc0
[ 1078.470121] [<ffffffff810b4214>] ? kvm_clock_read+0x24/0x50
[ 1078.470121] [<ffffffff810b4214>] ? kvm_clock_read+0x24/0x50
[ 1078.470121] [<ffffffff8107499d>] ? sched_clock+0x1d/0x30
[ 1078.470121] [<ffffffff81174be5>] ? sched_clock_local+0x25/0x90
[ 1078.470121] [<ffffffff83e4d831>] kernel_sendmsg+0x41/0x60
[ 1078.470121] [<ffffffff83e50b16>] sock_no_sendpage+0x96/0xb0
[ 1078.470121] [<ffffffff83fe72d8>] ? inet_sendpage+0x198/0x240
[ 1078.470121] [<ffffffff83fb4864>] tcp_sendpage+0x34/0x80
[ 1078.470121] [<ffffffff81aba729>] ? __const_udelay+0x29/0x30
[ 1078.470121] [<ffffffff811b2bf4>] ? __rcu_read_unlock+0x44/0xb0
[ 1078.470121] [<ffffffff83fe733f>] inet_sendpage+0x1ff/0x240
[ 1078.470121] [<ffffffff83fe7140>] ? inet_release+0x1d0/0x1d0
[ 1078.470121] [<ffffffff81192b79>] ? mark_held_locks+0x109/0x140
[ 1078.470121] [<ffffffff83e4a70b>] kernel_sendpage+0x1b/0x30
[ 1078.470121] [<ffffffff83e4a753>] sock_sendpage+0x33/0x40
[ 1078.470121] [<ffffffff81307118>] pipe_to_sendpage+0x78/0x80
[ 1078.470121] [<ffffffff813071ac>] splice_from_pipe_feed+0x8c/0x140
[ 1078.470121] [<ffffffff813070a0>] ? direct_splice_actor+0x40/0x40
[ 1078.470121] [<ffffffff812db39d>] ? pipe_lock+0x1d/0x20
[ 1078.470121] [<ffffffff813070a0>] ? direct_splice_actor+0x40/0x40
[ 1078.470121] [<ffffffff81307ae4>] __splice_from_pipe+0x44/0x80
[ 1078.470121] [<ffffffff813070a0>] ? direct_splice_actor+0x40/0x40
[ 1078.470121] [<ffffffff813070a0>] ? direct_splice_actor+0x40/0x40
[ 1078.470121] [<ffffffff81307b71>] splice_from_pipe+0x51/0x70
[ 1078.470121] [<ffffffff812d237c>] ? rw_verify_area+0xcc/0x100
[ 1078.470121] [<ffffffff81307bd5>] generic_splice_sendpage+0x15/0x20
[ 1078.470121] [<ffffffff8130821c>] do_splice+0x19c/0x310
[ 1078.470121] [<ffffffff81308449>] SyS_splice+0xb9/0x110
[ 1078.470121] [<ffffffff843a6ad0>] tracesys+0xdd/0xe2
Thanks,
Sasha
[-- Attachment #2: stats.gz --]
[-- Type: application/gzip, Size: 67893 bytes --]
next reply other threads:[~2013-12-19 5:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-19 5:53 Sasha Levin [this message]
2013-12-19 10:34 ` lockdep: BUG: MAX_LOCKDEP_ENTRIES too low! Peter Zijlstra
2013-12-19 14:02 ` Sasha Levin
2013-12-19 15:20 ` Peter Zijlstra
2013-12-19 15:39 ` Sasha Levin
2013-12-19 15:51 ` Peter Zijlstra
2013-12-19 15:59 ` Dave Jones
2013-12-19 16:01 ` Peter Zijlstra
2013-12-19 16:10 ` Dave Jones
2013-12-19 16:51 ` Sasha Levin
2013-12-20 4:05 ` Mike Galbraith
2013-12-19 15:49 ` Ingo Molnar
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=52B289F4.7060205@oracle.com \
--to=sasha.levin@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).