From: Dave Jones <davej@redhat.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: nfs lockdep report.
Date: Wed, 4 Apr 2007 01:03:45 -0400 [thread overview]
Message-ID: <20070404050345.GA22822@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
Don't know if this got reported yet. It's slightly stale
(against 2.6.21-rc4-git6), but I don't recall seeing
anything in the changelogs recently that would make this
irrelevant.
Dave
--
http://www.codemonkey.org.uk
[-- Attachment #2: Type: message/rfc822, Size: 9917 bytes --]
From: bugzilla@redhat.com
To: kernel-maint@redhat.com
Subject: [Bug 234140] New: possible circular locking dependency detected
Date: Tue, 27 Mar 2007 09:44:06 -0400
Message-ID: <bug-234140-176318@bugzilla.redhat.com>
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234140
Summary: possible circular locking dependency detected
Product: Fedora Core
Version: devel
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: kernel
AssignedTo: kernel-maint@redhat.com
ReportedBy: greenrd@greenrd.org
QAContact: bbrock@redhat.com
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
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
reply other threads:[~2007-04-04 5:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070404050345.GA22822@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.