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

[Ingo Molnar <mingo@elte.hu>]

* Anton Altaparmakov <aia21@cam.ac.uk> wrote:

> First an explanation of two relevant locks that are both going to 
> upset the validator.  I half expected this to happen given what has 
> happened so far.  The two locks are lcnbmp_lock and mftbmp_lock (both 
> are r/w semaphores).

thanks!

> Is the above description sufficient for you to fix it?

yeah. I have split off vol->lcnbmp_ino's locking rules (for mrec_lock 
and runlist.lock) from normal inode locking rules, and this fixed the 
file-writing dependency.

but i can still trigger a warning, and i think this time it's a real 
bug: if i mount NTFS with -o show_system_files, and i append data to the 
$Bitmap, then i get the dependency conflict attached further below.

While extending the $Bitmap manually is extremely evil, the filesystem 
should nevertheless not break - for example a script could do it by 
accident. I believe NTFS should either disallow writing to the $Bitmap 
(by forcing it to be readonly under all circumstances), or the writing 
should be made safe - right now if that happens in parallel to some 
other process extending an NTFS file then i think we could deadlock, 
right?

	Ingo

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cat/2532 is trying to acquire lock:
 (&vol->lcnbmp_lock){----}, at: [<c01e809d>] ntfs_cluster_alloc+0x10d/0x23a0

but task is already holding lock:
 (lcnbmp_mrec_lock){--..}, at: [<c01d5dc3>] map_mft_record+0x53/0x2c0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (lcnbmp_mrec_lock){--..}:
       [<c013948f>] lock_acquire+0x6f/0x90
       [<c0346163>] mutex_lock_nested+0x73/0x2a0
       [<c01d5dc3>] map_mft_record+0x53/0x2c0
       [<c01c5498>] ntfs_map_runlist_nolock+0x3d8/0x530
       [<c01c5b61>] ntfs_map_runlist+0x41/0x70
       [<c01c18d1>] ntfs_readpage+0x8c1/0x9a0
       [<c0142fac>] read_cache_page+0xac/0x150
       [<c01e20ad>] ntfs_statfs+0x41d/0x660
       [<c0163204>] vfs_statfs+0x54/0x70
       [<c0163238>] vfs_statfs64+0x18/0x30
       [<c0163334>] sys_statfs64+0x64/0xa0
       [<c0347dad>] sysenter_past_esp+0x56/0x8d

-> #1 (lcnbmp_runlist_lock){----}:
       [<c013948f>] lock_acquire+0x6f/0x90
       [<c0134c4c>] down_read+0x2c/0x40
       [<c01c184c>] ntfs_readpage+0x83c/0x9a0
       [<c0142fac>] read_cache_page+0xac/0x150
       [<c01e20ad>] ntfs_statfs+0x41d/0x660
       [<c0163204>] vfs_statfs+0x54/0x70
       [<c0163238>] vfs_statfs64+0x18/0x30
       [<c0163334>] sys_statfs64+0x64/0xa0
       [<c0347dad>] sysenter_past_esp+0x56/0x8d

-> #0 (&vol->lcnbmp_lock){----}:
       [<c013948f>] lock_acquire+0x6f/0x90
       [<c0134ccc>] down_write+0x2c/0x50
       [<c01e809d>] ntfs_cluster_alloc+0x10d/0x23a0
       [<c01c421d>] ntfs_attr_extend_allocation+0x5fd/0x14a0
       [<c01ca9d8>] ntfs_file_buffered_write+0x188/0x3880
       [<c01ce248>] ntfs_file_aio_write_nolock+0x178/0x210
       [<c01ce391>] ntfs_file_writev+0xb1/0x150
       [<c01ce44f>] ntfs_file_write+0x1f/0x30
       [<c0164eb9>] vfs_write+0x99/0x160
       [<c016584d>] sys_write+0x3d/0x70
       [<c0347dad>] sysenter_past_esp+0x56/0x8d

other info that might help us debug this:

3 locks held by cat/2532:
 #0:  (&inode->i_mutex){--..}, at: [<c03460e8>] mutex_lock+0x8/0x10
 #1:  (lcnbmp_runlist_lock){----}, at: [<c01c3d5e>] ntfs_attr_extend_allocation+0x13e/0x14a0
 #2:  (lcnbmp_mrec_lock){--..}, at: [<c01d5dc3>] map_mft_record+0x53/0x2c0

stack backtrace:
 [<c0104bf2>] show_trace+0x12/0x20
 [<c0104c19>] dump_stack+0x19/0x20
 [<c0136f11>] print_circular_bug_tail+0x61/0x70
 [<c01389af>] __lock_acquire+0x6df/0xd70
 [<c013948f>] lock_acquire+0x6f/0x90
 [<c0134ccc>] down_write+0x2c/0x50
 [<c01e809d>] ntfs_cluster_alloc+0x10d/0x23a0
 [<c01c421d>] ntfs_attr_extend_allocation+0x5fd/0x14a0
 [<c01ca9d8>] ntfs_file_buffered_write+0x188/0x3880
 [<c01ce248>] ntfs_file_aio_write_nolock+0x178/0x210
 [<c01ce391>] ntfs_file_writev+0xb1/0x150
 [<c01ce44f>] ntfs_file_write+0x1f/0x30
 [<c0164eb9>] vfs_write+0x99/0x160
 [<c016584d>] sys_write+0x3d/0x70
 [<c0347dad>] 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/