The patch titled
lockdep: annotate nfsd4 recover code
has been added to the -mm tree. Its filename is
lockdep-annotate-nfsd4-recover-code.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: lockdep: annotate nfsd4 recover code
From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.18-1.2724.lockdepPAE #1
> ---------------------------------------------
> nfsd/6884 is trying to acquire lock:
> (&inode->i_mutex){--..}, at: [<c04811e5>] vfs_rmdir+0x73/0xf4
>
> but task is already holding lock:
> (&inode->i_mutex){--..}, at: [<f8dfa621>]
> nfsd4_clear_clid_dir+0x1f/0x3d [nfsd]
>
> other info that might help us debug this:
> 3 locks held by nfsd/6884:
> #0: (hash_sem){----}, at: [<f8de05eb>] nfsd+0x181/0x2ea [nfsd]
> #1: (client_mutex){--..}, at: [<f8df6d19>]
> nfsd4_setclientid_confirm+0x3b/0x2cf [nfsd]
> #2: (&inode->i_mutex){--..}, at: [<f8dfa621>]
> nfsd4_clear_clid_dir+0x1f/0x3d [nfsd]
>
> stack backtrace:
> [<c040524d>] dump_trace+0x69/0x1af
> [<c04053ab>] show_trace_log_lvl+0x18/0x2c
> [<c040595f>] show_trace+0xf/0x11
> [<c0405a53>] dump_stack+0x15/0x17
> [<c043ca7a>] __lock_acquire+0x110/0x9b6
> [<c043d91e>] lock_acquire+0x5c/0x7a
> [<c061a41b>] __mutex_lock_slowpath+0xde/0x234
> [<c04811e5>] vfs_rmdir+0x73/0xf4
> [<f8dfa62b>] nfsd4_clear_clid_dir+0x29/0x3d [nfsd]
> [<f8dfa733>] nfsd4_remove_clid_dir+0xb8/0xf8 [nfsd]
> [<f8df6e90>] nfsd4_setclientid_confirm+0x1b2/0x2cf [nfsd]
> [<f8def19a>] nfsd4_proc_compound+0x137a/0x166c [nfsd]
> [<f8de00d5>] nfsd_dispatch+0xc5/0x180 [nfsd]
> [<f8d09d83>] svc_process+0x3bd/0x631 [sunrpc]
> [<f8de0604>] nfsd+0x19a/0x2ea [nfsd]
> [<c0404e27>] kernel_thread_helper+0x7/0x10
> DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10
> Leftover inexact backtrace:
> =======================
Some nesting annotation to the nfsd4 recovery code.
The vfs operations called will take dentry->d_inode->i_mutex.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Cc: Neil Brown <neilb@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
fs/nfsd/nfs4recover.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/nfsd/nfs4recover.c~lockdep-annotate-nfsd4-recover-code fs/nfsd/nfs4recover.c
--- a/fs/nfsd/nfs4recover.c~lockdep-annotate-nfsd4-recover-code
+++ a/fs/nfsd/nfs4recover.c
@@ -259,7 +259,7 @@ nfsd4_remove_clid_file(struct dentry *di
printk("nfsd4: non-file found in client recovery directory\n");
return -EINVAL;
}
- mutex_lock(&dir->d_inode->i_mutex);
+ mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT);
status = vfs_unlink(dir->d_inode, dentry);
mutex_unlock(&dir->d_inode->i_mutex);
return status;
@@ -274,7 +274,7 @@ nfsd4_clear_clid_dir(struct dentry *dir,
* any regular files anyway, just in case the directory was created by
* a kernel from the future.... */
nfsd4_list_rec_dir(dentry, nfsd4_remove_clid_file);
- mutex_lock(&dir->d_inode->i_mutex);
+ mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_PARENT);
status = vfs_rmdir(dir->d_inode, dentry);
mutex_unlock(&dir->d_inode->i_mutex);
return status;
_
Patches currently in -mm which might be from a.p.zijlstra@xxxxxxxxx are
origin.patch
lockdep-annotate-i386-apm.patch
rt-mutex-fixup-rt-mutex-debug-code.patch
git-input.patch
bonding-lockdep-annotation.patch
grab-swap-token-reordered.patch
new-scheme-to-preempt-swap-token.patch
new-scheme-to-preempt-swap-token-tidy.patch
lockdep-annotate-nfs-nfsd-in-kernel-sockets.patch
lockdep-annotate-nfs-nfsd-in-kernel-sockets-tidy.patch
remove-the-old-bd_mutex-lockdep-annotation.patch
new-bd_mutex-lockdep-annotation.patch
remove-lock_key-approach-to-managing-nested-bd_mutex-locks.patch
simplify-some-aspects-of-bd_mutex-nesting.patch
use-mutex_lock_nested-for-bd_mutex-to-avoid-lockdep-warning.patch
avoid-lockdep-warning-in-md.patch
lockdep-annotate-nfsd4-recover-code.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
