Bug 561763 - possible circular locking dependency detected
Summary: possible circular locking dependency detected
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 592512
TreeView+ depends on / blocked
 
Reported: 2010-02-04 08:51 UTC by Qian Cai
Modified: 2010-10-11 06:01 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 592512 (view as bug list)
Environment:
Last Closed: 2010-10-11 06:01:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Qian Cai 2010-02-04 08:51:49 UTC
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?

Comment 1 Miroslav Vadkerti 2010-02-05 12:01:54 UTC
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

Comment 2 Bug Zapper 2010-03-15 14:22:41 UTC
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

Comment 3 Mikko Tiihonen 2010-04-10 17:07:49 UTC
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.

Comment 4 Stanislaw Gruszka 2010-10-03 10:55:23 UTC
Still happen with 2.6.34 ?

Comment 5 yanfu,wang 2010-10-09 09:43:37 UTC
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

Comment 6 Stanislaw Gruszka 2010-10-11 06:01:58 UTC
Thanks for testing, I'm closing the bug.


Note You need to log in before you can comment on or make changes to this bug.