Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234140 - possible circular locking dependency detected
Summary: possible circular locking dependency detected
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-27 13:44 UTC by Robin Green
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-11 20:00:40 UTC


Attachments (Terms of Use)

Description Robin Green 2007-03-27 13:44:06 UTC
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 06:27:57 UTC
Have you seen this again on a more recent kernel (particularly any of the .23rc
based kernels) ?


Comment 2 Robin Green 2007-10-11 09:14:38 UTC
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.