Erez Zadok reports:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.24-rc6-unionfs2 #80
-------------------------------------------------------
umount.nfs4/4017 is trying to acquire lock:
(&(&clp->cl_renewd)->work){--..}, at: [<
c0223e53>]
__cancel_work_timer+0x83/0x17f
but task is already holding lock:
(&clp->cl_sem){----}, at: [<
f8879897>] nfs4_kill_renewd+0x17/0x29 [nfs]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&clp->cl_sem){----}:
[<
c0230699>] __lock_acquire+0x9cc/0xb95
[<
c0230c39>] lock_acquire+0x5f/0x78
[<
c0397cb8>] down_read+0x3a/0x4c
[<
f88798e6>] nfs4_renew_state+0x1c/0x1b8 [nfs]
[<
c0223821>] run_workqueue+0xd9/0x1ac
[<
c0224220>] worker_thread+0x7a/0x86
[<
c0226b49>] kthread+0x3b/0x62
[<
c02033a3>] kernel_thread_helper+0x7/0x10
[<
ffffffff>] 0xffffffff
-> #0 (&(&clp->cl_renewd)->work){--..}:
[<
c0230589>] __lock_acquire+0x8bc/0xb95
[<
c0230c39>] lock_acquire+0x5f/0x78
[<
c0223e87>] __cancel_work_timer+0xb7/0x17f
[<
c0223f5a>] cancel_delayed_work_sync+0xb/0xd
[<
f887989e>] nfs4_kill_renewd+0x1e/0x29 [nfs]
[<
f885a8f6>] nfs_free_client+0x37/0x9e [nfs]
[<
f885ab20>] nfs_put_client+0x5d/0x62 [nfs]
[<
f885ab9a>] nfs_free_server+0x75/0xae [nfs]
[<
f8862672>] nfs4_kill_super+0x27/0x2b [nfs]
[<
c0258aab>] deactivate_super+0x3f/0x51
[<
c0269668>] mntput_no_expire+0x42/0x67
[<
c025d0e4>] path_release_on_umount+0x15/0x18
[<
c0269d30>] sys_umount+0x1a3/0x1cb
[<
c0269d71>] sys_oldumount+0x19/0x1b
[<
c02026ca>] sysenter_past_esp+0x5f/0xa5
[<
ffffffff>] 0xffffffff
Looking at the code, it would seem that taking the clp->cl_sem in
nfs4_kill_renewd is completely redundant, since we're already guaranteed to
have exclusive access to the nfs_client (we're shutting down).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>