Messages in this thread | | | Date | Sat, 10 Jun 2006 09:59:54 +0200 | From | Ingo Molnar <> | Subject | Re: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected! |
| |
* Anton Altaparmakov <aia21@cam.ac.uk> wrote:
> The normal access pattern (B) where the runlist lock is always taken > first. And the mft record lock is taken second and only if the > runlist is incomplete in-memory. > > Of course on file modification, this is also the case, the runlist > lock is taken first, then the mft record lock is taken and thus both > the runlist and the inode can be updated with the new data (e.g. on a > file extend).
thanks for the detailed explanation!
I have annotated the code for the lock validator as much as i could, by:
- excluding ntfs_fill_super() from the locking rules,
- 'splitting' the MFT's mrec_lock and runlist->lock locking rules from the other inodes's locking rules,
- splitting the mrec_lock rules of extent inodes. (We map them recursively while having the main inode mft record mapped. The nesting is safe because inode->extent_inode is a noncircular relation.)
Still there seems to be a case that the validator does not grok: load_attribute_list() seems to take the lock in the opposite order from what you described above. What locking detail am i missing? [let me know if you need all dependency events leading up to this message from the validator]
Ingo
======================================================= [ INFO: possible circular locking dependency detected ] ------------------------------------------------------- ls/2581 is trying to acquire lock: (&rl->lock){----}, at: [<c01c1f5b>] load_attribute_list+0xfb/0x3c0
but task is already holding lock: (&ni->mrec_lock){--..}, at: [<c01d50c5>] map_mft_record_type+0x55/0x2d0
which lock already depends on the new lock, which could lead to circular locking dependencies.
the existing dependency chain (in reverse order) is:
-> #1 (&ni->mrec_lock){--..}: [<c01394df>] lock_acquire+0x6f/0x90 [<c0346183>] mutex_lock_nested+0x73/0x2a0 [<c01d5e43>] map_mft_record+0x53/0x2c0 [<c01c54f8>] ntfs_map_runlist_nolock+0x3d8/0x530 [<c01c5bc1>] ntfs_map_runlist+0x41/0x70 [<c01c1929>] ntfs_readpage+0x8c9/0x9b0 [<c0142ffc>] read_cache_page+0xac/0x150 [<c01e212d>] ntfs_statfs+0x41d/0x660 [<c0163254>] vfs_statfs+0x54/0x70 [<c0163288>] vfs_statfs64+0x18/0x30 [<c0163384>] sys_statfs64+0x64/0xa0 [<c0347dcd>] sysenter_past_esp+0x56/0x8d
-> #0 (&rl->lock){----}: [<c01394df>] lock_acquire+0x6f/0x90 [<c0134c8a>] down_read_nested+0x2a/0x40 [<c01c1f5b>] load_attribute_list+0xfb/0x3c0 [<c01d323e>] ntfs_read_locked_inode+0xcee/0x15d0 [<c01d4735>] ntfs_iget+0x55/0x80 [<c01db3da>] ntfs_lookup+0x14a/0x740 [<c01736b6>] do_lookup+0x126/0x150 [<c0173ef3>] __link_path_walk+0x813/0xe50 [<c017457c>] link_path_walk+0x4c/0xf0 [<c0174a2d>] do_path_lookup+0xad/0x260 [<c0175228>] __user_walk_fd+0x38/0x60 [<c016e3be>] vfs_lstat_fd+0x1e/0x50 [<c016e401>] vfs_lstat+0x11/0x20 [<c016ec04>] sys_lstat64+0x14/0x30 [<c0347dcd>] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
2 locks held by ls/2581: #0: (&inode->i_mutex){--..}, at: [<c0346108>] mutex_lock+0x8/0x10 #1: (&ni->mrec_lock){--..}, at: [<c01d50c5>] map_mft_record_type+0x55/0x2d0
stack backtrace: [<c0104bf2>] show_trace+0x12/0x20 [<c0104c19>] dump_stack+0x19/0x20 [<c0136ef1>] print_circular_bug_tail+0x61/0x70 [<c01389ff>] __lock_acquire+0x74f/0xde0 [<c01394df>] lock_acquire+0x6f/0x90 [<c0134c8a>] down_read_nested+0x2a/0x40 [<c01c1f5b>] load_attribute_list+0xfb/0x3c0 [<c01d323e>] ntfs_read_locked_inode+0xcee/0x15d0 [<c01d4735>] ntfs_iget+0x55/0x80 [<c01db3da>] ntfs_lookup+0x14a/0x740 [<c01736b6>] do_lookup+0x126/0x150 [<c0173ef3>] __link_path_walk+0x813/0xe50 [<c017457c>] link_path_walk+0x4c/0xf0 [<c0174a2d>] do_path_lookup+0xad/0x260 [<c0175228>] __user_walk_fd+0x38/0x60 [<c016e3be>] vfs_lstat_fd+0x1e/0x50 [<c016e401>] vfs_lstat+0x11/0x20 [<c016ec04>] sys_lstat64+0x14/0x30 [<c0347dcd>] sysenter_past_esp+0x56/0x8d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |