Re: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected!

[Ingo Molnar]

* Anton Altaparmakov <aia21@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/