* Anton Altaparmakov <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
