Hi.
I managed to get following circular locking bug during fs development.
I can not reproduce it and it was caught during another fs development,
so that can be related, but as is it looks like a bug.
Hope this helps:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.23-pohmelfs #4
-------------------------------------------------------
bash/4116 is trying to acquire lock:
(&journal->j_list_lock){--..}, at: [<d082548a>]
journal_try_to_free_buffers+0xd4/0x187 [jbd]
but task is already holding lock:
(inode_lock){--..}, at: [<c017a466>] drop_pagecache+0x48/0xd8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (inode_lock){--..}:
[<c013a487>] __lock_acquire+0xa66/0xc48
[<c013a6e3>] lock_acquire+0x7a/0x94
[<c02530ab>] _spin_lock+0x38/0x62
[<c0179f83>] __mark_inode_dirty+0xce/0x147
[<c017d912>] __set_page_dirty+0xd0/0xdf
[<c017d9ac>] mark_buffer_dirty+0x8b/0x92
[<d0823179>] __journal_temp_unlink_buffer+0x174/0x17b [jbd]
[<d082339e>] __journal_unfile_buffer+0xb/0x15 [jbd]
[<d0823412>] __journal_refile_buffer+0x6a/0xe3 [jbd]
[<d08265db>] journal_commit_transaction+0xf46/0x11eb [jbd]
[<d0829da8>] kjournald+0xb5/0x1c1 [jbd]
[<c012fe44>] kthread+0x3b/0x63
[<c010373f>] kernel_thread_helper+0x7/0x10
[<ffffffff>] 0xffffffff
-> #0 (&journal->j_list_lock){--..}:
[<c013a373>] __lock_acquire+0x952/0xc48
[<c013a6e3>] lock_acquire+0x7a/0x94
[<c02530ab>] _spin_lock+0x38/0x62
[<d082548a>] journal_try_to_free_buffers+0xd4/0x187 [jbd]
[<d0863760>] ext3_releasepage+0x68/0x74 [ext3]
[<c01478e0>] try_to_release_page+0x33/0x44
[<c014c65f>] __invalidate_mapping_pages+0x74/0xe0
[<c017a48e>] drop_pagecache+0x70/0xd8
[<c017a52c>] drop_caches_sysctl_handler+0x36/0x4e
[<c019312f>] proc_sys_write+0x6b/0x85
[<c0161f17>] vfs_write+0x82/0xb8
[<c016240c>] sys_write+0x3d/0x61
[<c0102ac2>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
2 locks held by bash/4116:
#0: (&type->s_umount_key#11){----}, at: [<c017a456>] drop_pagecache+0x38/0xd8
#1: (inode_lock){--..}, at: [<c017a466>] drop_pagecache+0x48/0xd8
stack backtrace:
[<c0103ae8>] show_trace_log_lvl+0x1a/0x2f
[<c0104676>] show_trace+0x12/0x14
[<c010468e>] dump_stack+0x16/0x18
[<c013865a>] print_circular_bug_tail+0x5f/0x68
[<c013a373>] __lock_acquire+0x952/0xc48
[<c013a6e3>] lock_acquire+0x7a/0x94
[<c02530ab>] _spin_lock+0x38/0x62
[<d082548a>] journal_try_to_free_buffers+0xd4/0x187 [jbd]
[<d0863760>] ext3_releasepage+0x68/0x74 [ext3]
[<c01478e0>] try_to_release_page+0x33/0x44
[<c014c65f>] __invalidate_mapping_pages+0x74/0xe0
[<c017a48e>] drop_pagecache+0x70/0xd8
[<c017a52c>] drop_caches_sysctl_handler+0x36/0x4e
[<c019312f>] proc_sys_write+0x6b/0x85
[<c0161f17>] vfs_write+0x82/0xb8
[<c016240c>] sys_write+0x3d/0x61
[<c0102ac2>] syscall_call+0x7/0xb
=======================
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
