Bug 234140 - possible circular locking dependency detected
possible circular locking dependency detected
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-27 09:44 EDT by Robin Green
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-11 16:00:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Green 2007-03-27 09:44:06 EDT
Description of problem:
I got the "possible circular locking dependency detected" message in my
/var/log/messages, as shown in this excerpt:

Mar 25 21:14:57 greenrd sshd(pam_unix)[28494]: session opened for user greenrd
by (uid=0)
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel:
=======================================================
Mar 25 21:15:10 greenrd kernel: [ INFO: possible circular locking dependency
detected ]
Mar 25 21:15:10 greenrd kernel: 2.6.20-1.3017.fc7 #1
Mar 25 21:15:10 greenrd kernel:
-------------------------------------------------------
Mar 25 21:15:10 greenrd kernel: kdesktop/28739 is trying to acquire lock:
Mar 25 21:15:10 greenrd kernel:  (&inode->i_mutex){--..}, at:
[<ffffffff802622fe>] mutex_lock+0x2a/0x2e
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: but task is already holding lock:
Mar 25 21:15:10 greenrd kernel:  (&mm->mmap_sem){----}, at: [<ffffffff802243dd>]
sys_mmap+0x73/0x119
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: which lock already depends on the new lock.
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: the existing dependency chain (in reverse order) is:
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: -> #1 (&mm->mmap_sem){----}:
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802a3574>]
__lock_acquire+0xa27/0xbd1
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802a3b14>] lock_acquire+0x4c/0x65
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802660d8>]
do_page_fault+0x3b5/0x7ed
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8029e725>] down_read+0x3e/0x4a
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802660d8>]
do_page_fault+0x3b5/0x7ed
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802622bb>]
__mutex_lock_slowpath+0x280/0x299
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802a24c7>]
mark_held_locks+0x53/0x7a
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802622bb>]
__mutex_lock_slowpath+0x280/0x299
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802642dd>] error_exit+0x0/0x96
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802e1897>] pipe_read+0x106/0x374
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802e185e>] pipe_read+0xcd/0x374
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8020d14d>] do_sync_read+0xe2/0x126
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8029c2eb>]
autoremove_wake_function+0x0/0x38
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802bafb8>]
audit_syscall_entry+0x148/0x17e
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8020b4d2>] vfs_read+0xcc/0x175
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802114bc>] sys_read+0x47/0x6f
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8025c2b5>] tracesys+0xdc/0xe1
Mar 25 21:15:10 greenrd kernel:        [<ffffffffffffffff>] 0xffffffffffffffff
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: -> #0 (&inode->i_mutex){--..}:
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802a346c>]
__lock_acquire+0x91f/0xbd1
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802a3b14>] lock_acquire+0x4c/0x65
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802622fe>] mutex_lock+0x2a/0x2e
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8026213a>]
__mutex_lock_slowpath+0xff/0x299
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8020e1ca>]
do_mmap_pgoff+0x45b/0x7fa
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802622fe>] mutex_lock+0x2a/0x2e
Mar 25 21:15:10 greenrd kernel:        [<ffffffff88466ca0>]
nfs_revalidate_mapping+0x6d/0xac [nfs]
Mar 25 21:15:10 greenrd kernel:        [<ffffffff88464784>]
nfs_file_mmap+0x4d/0x65 [nfs]
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8020e26c>]
do_mmap_pgoff+0x4fd/0x7fa
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802a26ca>]
trace_hardirqs_on+0x136/0x15a
Mar 25 21:15:10 greenrd kernel:        [<ffffffff802243fa>] sys_mmap+0x90/0x119
Mar 25 21:15:10 greenrd kernel:        [<ffffffff8025c2b5>] tracesys+0xdc/0xe1
Mar 25 21:15:10 greenrd kernel:        [<ffffffffffffffff>] 0xffffffffffffffff
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: other info that might help us debug this:
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: 1 lock held by kdesktop/28739:
Mar 25 21:15:10 greenrd kernel:  #0:  (&mm->mmap_sem){----}, at:
[<ffffffff802243dd>] sys_mmap+0x73/0x119
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: stack backtrace:
Mar 25 21:15:10 greenrd kernel: 
Mar 25 21:15:10 greenrd kernel: Call Trace:
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802a1b0f>]
print_circular_bug_tail+0x70/0x7b
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802a346c>] __lock_acquire+0x91f/0xbd1
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802a3b14>] lock_acquire+0x4c/0x65
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802622fe>] mutex_lock+0x2a/0x2e
Mar 25 21:15:10 greenrd kernel:  [<ffffffff8026213a>]
__mutex_lock_slowpath+0xff/0x299
Mar 25 21:15:10 greenrd kernel:  [<ffffffff8020e1ca>] do_mmap_pgoff+0x45b/0x7fa
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802622fe>] mutex_lock+0x2a/0x2e
Mar 25 21:15:10 greenrd kernel:  [<ffffffff88466ca0>]
:nfs:nfs_revalidate_mapping+0x6d/0xac
Mar 25 21:15:10 greenrd kernel:  [<ffffffff88464784>] :nfs:nfs_file_mmap+0x4d/0x65
Mar 25 21:15:10 greenrd kernel:  [<ffffffff8020e26c>] do_mmap_pgoff+0x4fd/0x7fa
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802a26ca>] trace_hardirqs_on+0x136/0x15a
Mar 25 21:15:10 greenrd kernel:  [<ffffffff802243fa>] sys_mmap+0x90/0x119
Mar 25 21:15:10 greenrd kernel:  [<ffffffff8025c2b5>] tracesys+0xdc/0xe1
Mar 25 21:15:10 greenrd kernel: 


Version-Release number of selected component (if applicable):
kernel-2.6.20-1.3017.fc7

How to reproduce:
No idea
Comment 1 Dave Jones 2007-10-11 02:27:57 EDT
Have you seen this again on a more recent kernel (particularly any of the .23rc
based kernels) ?
Comment 2 Robin Green 2007-10-11 05:14:38 EDT
No (but I'm not using NFS any more, so who knows if it's still there or not).

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