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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox