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
Have you seen this again on a more recent kernel (particularly any of the .23rc based kernels) ?
No (but I'm not using NFS any more, so who knows if it's still there or not).