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

Ingo Molnar
2006-06-12T08:32:18Z

* 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