Description of problem: When running the connectathon testsuite on a NFSv4 root, ./runcthon --server 10.34.33.104 --serverdir /nfs --onlyv4 ./server -b -F nfs4 -o proto=tcp -m /mnt/nfsv4tcp -p /nfs/nfsv4tcp 10.34.33.104 Waiting for 'b' to finish... ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.33-0.26.rc6.git1.fc13.i686.PAE #1 ------------------------------------------------------- test5/26460 is trying to acquire lock: (&sb->s_type->i_mutex_key#16){+.+.+.}, at: [<f8e2b9a4>] nfs_revalidate_mapping+0x67/0xa1 [nfs] but task is already holding lock: (&mm->mmap_sem){++++++}, at: [<c04cf27c>] sys_mmap_pgoff+0xab/0xee which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++++}: [<c046a958>] __lock_acquire+0xa17/0xb76 [<c046ab4a>] lock_acquire+0x93/0xb1 [<c04c78e9>] might_fault+0x69/0x86 [<c05cb432>] copy_to_user+0x34/0x10a [<c04f37ec>] filldir64+0x9c/0xd0 [<f8e2779f>] nfs_do_filldir+0x310/0x3bb [nfs] [<f8e27ed8>] nfs_readdir+0x68e/0x70c [nfs] [<c04f3a14>] vfs_readdir+0x6d/0x99 [<c04f3aa8>] sys_getdents64+0x68/0xaa [<c0408b5f>] sysenter_do_call+0x12/0x38 -> #0 (&sb->s_type->i_mutex_key#16){+.+.+.}: [<c046a85a>] __lock_acquire+0x919/0xb76 [<c046ab4a>] lock_acquire+0x93/0xb1 [<c07c1afb>] __mutex_lock_common+0x32/0x30a [<c07c1e80>] mutex_lock_nested+0x35/0x3d [<f8e2b9a4>] nfs_revalidate_mapping+0x67/0xa1 [nfs] [<f8e291ca>] nfs_file_mmap+0x55/0x5d [nfs] [<c04ced93>] mmap_region+0x250/0x3f7 [<c04cf181>] do_mmap_pgoff+0x247/0x297 [<c04cf295>] sys_mmap_pgoff+0xc4/0xee [<c0408b5f>] sysenter_do_call+0x12/0x38 other info that might help us debug this: 1 lock held by test5/26460: #0: (&mm->mmap_sem){++++++}, at: [<c04cf27c>] sys_mmap_pgoff+0xab/0xee stack backtrace: Pid: 26460, comm: test5 Not tainted 2.6.33-0.26.rc6.git1.fc13.i686.PAE #1 Call Trace: [<c07c091d>] ? printk+0x14/0x17 [<c0469c13>] print_circular_bug+0x8a/0x96 [<c046a85a>] __lock_acquire+0x919/0xb76 [<c045e4f7>] ? sched_clock_cpu+0x125/0x12d [<c046ab4a>] lock_acquire+0x93/0xb1 [<f8e2b9a4>] ? nfs_revalidate_mapping+0x67/0xa1 [nfs] [<c07c1afb>] __mutex_lock_common+0x32/0x30a [<f8e2b9a4>] ? nfs_revalidate_mapping+0x67/0xa1 [nfs] [<f8e47f55>] ? rcu_read_unlock+0x0/0x1e [nfs] [<c07c1e80>] mutex_lock_nested+0x35/0x3d [<f8e2b9a4>] ? nfs_revalidate_mapping+0x67/0xa1 [nfs] [<f8e2b9a4>] nfs_revalidate_mapping+0x67/0xa1 [nfs] [<f8e291ca>] nfs_file_mmap+0x55/0x5d [nfs] [<c04ced93>] mmap_region+0x250/0x3f7 [<c04cf181>] do_mmap_pgoff+0x247/0x297 [<c04cf295>] sys_mmap_pgoff+0xc4/0xee [<c0408b5f>] sysenter_do_call+0x12/0x38 Version-Release number of selected component (if applicable): kernel-2.6.33-0.26.rc6.git1.fc13 nfs-utils-1.2.1-16.fc13 How reproducible: always Steps to Reproduce: 1. following the instruction here. http://fedoraproject.org/wiki/QA:Testcase_nfs_connectathon Actual results: Warnings in dmesg. Expected results: No warning in dmesg?
Same failure in connectathon testsuite with krb5: https://fedoraproject.org/wiki/QA:Testcase_nfs_connectathon_secure ./runcthon --server dhcp-lab-104.englab.brq.redhat.com --serverdir /nfs --onlyv4 --onlykrb5
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I see the same lockdep warning on 2.6.33.1-19.fc13.x86_64 kernel on every boot when nfs4 home directory is mounted.
Still happen with 2.6.34 ?
I verified on 2.6.34.7-59.fc13 kernel , no warning shown on dmesg and test done successfully. TESTOUT.log: Sat Oct 9 03:07:11 EDT 2010 serverdir=/nfs ./server -b -F nfs4 -o proto=tcp -m /mnt/nfsv4tcp -p /nfs/nfsv4tcp 10.16.45.33 Waiting for 'b' to finish... Done: 03:50:43 AM ./server -g -F nfs4 -o proto=tcp -m /mnt/nfsv4tcp -p /nfs/nfsv4tcp 10.16.45.33 Waiting for 'g' to finish... Done: 03:57:50 AM ./server -s -F nfs4 -o proto=tcp -m /mnt/nfsv4tcp -p /nfs/nfsv4tcp 10.16.45.33 Waiting for 's' to finish... Done: 04:33:19 AM ./server -l -F nfs4 -o proto=tcp -m /mnt/nfsv4tcp -p /nfs/nfsv4tcp 10.16.45.33 Waiting for 'l' to finish... Done: 05:06:14 AM
Thanks for testing, I'm closing the bug.