Re: CIFS & Lockdep warnings

[Andrew Morton]

On Mon, 14 Aug 2006 11:05:03 +1000 (EST)
Srihari Vijayaraghavan <sriharivijayaraghavan@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/