On Mon, 14 Aug 2006 11:05:03 +1000 (EST)
Srihari Vijayaraghavan <[email protected]> wrote:
> This is observed on 2.6.18-rc4 on SUSE 10.1 x86 on
> P-IV. The volume is question was mounted from a
> Windows 2003 server.
>
> =======================================================
> [ INFO: possible circular locking dependency detected
> ]
> -------------------------------------------------------
> cp/11790 is trying to acquire lock:
> (iprune_mutex){--..}, at: [<c029e364>]
> mutex_lock+0x19/0x20
>
> but task is already holding lock:
> (&inode->i_mutex){--..}, at: [<c029e364>]
> mutex_lock+0x19/0x20
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&inode->i_mutex){--..}:
> [<c012a1c0>] lock_acquire+0x56/0x73
> [<c029e205>] __mutex_lock_slowpath+0xa6/0x1ec
> [<c029e364>] mutex_lock+0x19/0x20
> [<e3cd2b7a>] ntfs_put_inode+0x3e/0x79 [ntfs]
> [<c0169ac1>] iput+0x33/0x70
> [<c017738e>] inotify_unmount_inodes+0x12e/0x15f
> [<c016a55c>] invalidate_inodes+0x38/0xd1
> [<c01599b3>] generic_shutdown_super+0x5a/0x108
> [<c0159a81>] kill_block_super+0x20/0x36
> [<c0159b56>] deactivate_super+0x61/0x78
> [<c016c561>] mntput_no_expire+0x44/0x78
> [<c015f536>] path_release_on_umount+0x16/0x1d
> [<c016d692>] sys_umount+0x1d2/0x208
> [<c016d6d5>] sys_oldumount+0xd/0xf
> [<c0102cfb>] syscall_call+0x7/0xb
NTFS takes i_mutex inside iprune_mutex. NTFS _should_ be deadlocking
because of this (iprune_mutex nests inside i_mutex on the write() path) but
somehow it gets away with it.
> -> #0 (iprune_mutex){--..}:
> [<c012a1c0>] lock_acquire+0x56/0x73
> [<c029e205>] __mutex_lock_slowpath+0xa6/0x1ec
> [<c029e364>] mutex_lock+0x19/0x20
> [<c016a3a2>] shrink_icache_memory+0x33/0x1b5
> [<c0142b56>] shrink_slab+0xce/0x125
> [<c0143385>] try_to_free_pages+0x125/0x1cc
> [<c013f8a8>] __alloc_pages+0x184/0x26d
> [<c013ca52>]
> generic_file_buffered_write+0x15a/0x53d
> [<c013d175>]
> __generic_file_aio_write_nolock+0x340/0x38d
> [<c013d223>] generic_file_aio_write+0x61/0xb3
> [<e3d8a326>] cifs_file_aio_write+0x23/0x43
> [cifs]
> [<c0153bb3>] do_sync_write+0x9d/0xce
> [<c0154437>] vfs_write+0xaa/0x14e
> [<c015496e>] sys_write+0x3a/0x61
> [<c0102cfb>] syscall_call+0x7/0xb
CIFS takes i_prune_mutex inside i_mutex.
There's no deadlock here. Arguably lockdep should be treating i_mutex in
filesystem A as being a different class from i_mutex from filesystem B.
-
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]
