From: Peter Zijlstra <peterz@infradead.org>
To: Alexander Beregalov <a.beregalov@gmail.com>
Cc: "linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Chris Mason <chris.mason@oracle.com>
Subject: Re: next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low!
Date: Wed, 11 Feb 2009 14:04:27 +0100 [thread overview]
Message-ID: <1234357467.23438.151.camel@twins> (raw)
In-Reply-To: <a4423d670902110452s5fb6d041l2363c8ad9b9618fb@mail.gmail.com>
On Wed, 2009-02-11 at 15:52 +0300, Alexander Beregalov wrote:
> 2009/2/11 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, 2009-02-11 at 13:24 +0100, Peter Zijlstra wrote:
> >> On Wed, 2009-02-11 at 13:23 +0100, Peter Zijlstra wrote:
> >> > On Wed, 2009-02-11 at 15:14 +0300, Alexander Beregalov wrote:
> >> > > Hi
> >> > >
> >> > > Full dmesg is attached.
> >> > >
> >> > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> >> > > .... MAX_LOCKDEP_SUBCLASSES: 8
> >> > > .... MAX_LOCK_DEPTH: 48
> >> > > .... MAX_LOCKDEP_KEYS: 8191
> >> > > .... CLASSHASH_SIZE: 4096
> >> > > .... MAX_LOCKDEP_ENTRIES: 8192
> >> > > .... MAX_LOCKDEP_CHAINS: 16384
> >> > > .... CHAINHASH_SIZE: 8192
> >> > > memory used by lock dependency info: 4351 kB
> >> > > per task-struct memory footprint: 2688 bytes
> >> > > <..>
> >> > > BUG: MAX_LOCKDEP_SUBCLASSES too low!
> >> > > turning off the locking correctness validator.
> >> >
> >> > Is this an allyesconfig or something other massive bloated?
> >>
> >> Sorry, not playing attention, its SUB classes.. let me look at that,
> >> that smells like a rotten annotation.
> >
> > Could you run with the below patch, so that we can see where this
> > happens?
Tssk, Chris what you have been doing?
> BUG: MAX_LOCKDEP_SUBCLASSES too low!
> turning off the locking correctness validator.
> Pid: 2105, comm: btrfs-endio-wri Not tainted 2.6.29-rc4-next-20090211-dirty #2
> Call Trace:
> [<ffffffff8026cbf9>] __lock_acquire+0x6b9/0x12c0
> [<ffffffff8026d891>] lock_acquire+0x91/0xc0
> [<ffffffff80447324>] ? btrfs_tree_lock+0xc4/0x160
> [<ffffffff8062eb36>] _spin_lock_nested+0x46/0x80
> [<ffffffff80447324>] ? btrfs_tree_lock+0xc4/0x160
> [<ffffffff80447324>] btrfs_tree_lock+0xc4/0x160
> [<ffffffff804471a0>] ? btrfs_wake_function+0x0/0x10
> [<ffffffff8040bce6>] btrfs_init_new_buffer+0xa6/0x150
> [<ffffffff80412fa1>] btrfs_alloc_free_block+0x81/0x90
> [<ffffffff80402a16>] __btrfs_cow_block+0x7a6/0xb70
> [<ffffffff804034e2>] btrfs_cow_block+0x112/0x2d0
> [<ffffffff804072f3>] btrfs_search_slot+0x223/0xb00
> [<ffffffff80235a99>] ? sub_preempt_count+0xa9/0xf0
> [<ffffffff804178d1>] btrfs_lookup_csum+0x61/0x150
> [<ffffffff8026c2ed>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff80418356>] btrfs_csum_file_blocks+0xc6/0x7d0
> [<ffffffff802c2315>] ? kmem_cache_free+0xb5/0x110
> [<ffffffff802c2315>] ? kmem_cache_free+0xb5/0x110
> [<ffffffff8026c2ed>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff80437c76>] ? free_extent_state+0x46/0x70
> [<ffffffff80439462>] ? clear_extent_bit+0xe2/0x2e0
> [<ffffffff8042166a>] add_pending_csums+0x4a/0x70
> [<ffffffff80422ac5>] btrfs_finish_ordered_io+0x115/0x1e0
> [<ffffffff80422ba0>] btrfs_writepage_end_io_hook+0x10/0x20
> [<ffffffff8043abf4>] end_bio_extent_writepage+0x104/0x1e0
> [<ffffffff8026c282>] ? trace_hardirqs_on_caller+0x182/0x1e0
> [<ffffffff802ef0cc>] bio_endio+0x1c/0x40
> [<ffffffff8041b02b>] end_workqueue_fn+0xeb/0x120
> [<ffffffff804446ea>] worker_loop+0x7a/0x1b0
> [<ffffffff80444670>] ? worker_loop+0x0/0x1b0
> [<ffffffff80259126>] kthread+0x56/0x90
> [<ffffffff8020cc5a>] child_rip+0xa/0x20
> [<ffffffff80235969>] ? finish_task_switch+0x89/0x110
> [<ffffffff8062f546>] ? _spin_unlock_irq+0x36/0x60
> [<ffffffff8020c640>] ? restore_args+0x0/0x30
> [<ffffffff802590d0>] ? kthread+0x0/0x90
> [<ffffffff8020cc50>] ? child_rip+0x0/0x20
next prev parent reply other threads:[~2009-02-11 13:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-11 12:14 next-20090211: BUG: MAX_LOCKDEP_SUBCLASSES too low! Alexander Beregalov
2009-02-11 12:23 ` Peter Zijlstra
2009-02-11 12:24 ` Peter Zijlstra
2009-02-11 12:26 ` Peter Zijlstra
2009-02-11 12:52 ` Alexander Beregalov
2009-02-11 13:04 ` Peter Zijlstra [this message]
2009-02-11 14:00 ` Peter Zijlstra
2009-02-11 14:01 ` Chris Mason
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=1234357467.23438.151.camel@twins \
--to=peterz@infradead.org \
--cc=a.beregalov@gmail.com \
--cc=chris.mason@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
/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