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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html