* Anton Altaparmakov <[email protected]> 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 [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]
