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
-> #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
other info that might help us debug this:
2 locks held by cp/11790:
#0: (&inode->i_mutex){--..}, at: [<c029e364>]
mutex_lock+0x19/0x20
#1: (shrinker_rwsem){----}, at: [<c0142aa8>]
shrink_slab+0x20/0x125
stack backtrace:
[<c01033da>] show_trace_log_lvl+0x57/0x157
[<c0103a28>] show_trace+0x16/0x19
[<c0103ac9>] dump_stack+0x1a/0x1f
[<c0129551>] print_circular_bug_tail+0x59/0x64
[<c0129d6e>] __lock_acquire+0x812/0x9a3
[<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
DWARF2 unwinder stuck at syscall_call+0x7/0xb
Leftover inexact backtrace:
[<c0103a28>] show_trace+0x16/0x19
[<c0103ac9>] dump_stack+0x1a/0x1f
[<c0129551>] print_circular_bug_tail+0x59/0x64
[<c0129d6e>] __lock_acquire+0x812/0x9a3
[<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
More info on request.
Thanks
____________________________________________________
On Yahoo!7
360?: Your own space to share what you want with who you want!
http://www.yahoo7.com.au/360
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.
--- Andrew Morton <[email protected]> wrote:
> On Mon, 14 Aug 2006 11:05:03 +1000 (EST)
> Srihari Vijayaraghavan
> <[email protected]> wrote:
> [...]
> 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.
Yup. An NTFS volume (thro' USB Storage) was also
mounted at that time. (And the copy operation may have
been between NFTS & CIFS volumes)
Thanks
____________________________________________________
On Yahoo!7
Photos: Unlimited free storage ? keep all your photos in one place!
http://au.photos.yahoo.com
On Sun, 2006-08-13 at 18:51 -0700, Andrew Morton wrote:
> 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.
Directories are not subject to write(2) or at least not last time I
checked. And ntfs_put_inode() only operates on directories... To quote
current 2.6 kernel/fs/ntfs/inode.c:
void ntfs_put_inode(struct inode *vi)
{
if (S_ISDIR(vi->i_mode) && atomic_read(&vi->i_count) == 2) {
ntfs_inode *ni = NTFS_I(vi);
if (NInoIndexAllocPresent(ni)) {
struct inode *bvi = NULL;
mutex_lock(&vi->i_mutex);
if (atomic_read(&vi->i_count) == 2) {
bvi = ni->itype.index.bmp_ino;
if (bvi)
ni->itype.index.bmp_ino = NULL;
}
mutex_unlock(&vi->i_mutex);
if (bvi)
iput(bvi);
}
}
}
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/