From: Peter Zijlstra <peterz@infradead.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: NFS: possible circular locking i_mutex <> mmap_sem
Date: Thu, 18 Jun 2009 18:48:08 +0200 [thread overview]
Message-ID: <1245343689.13761.23623.camel@twins> (raw)
In-Reply-To: <20090618030238.GA850@localhost>
On Thu, 2009-06-18 at 11:02 +0800, Wu Fengguang wrote:
> > > [ 2638.515865] =======================================================
> > > [ 2638.519743] [ INFO: possible circular locking dependency detected ]
> > > [ 2638.519743] 2.6.30-rc8-mm1 #307
> > > [ 2638.519743] -------------------------------------------------------
> > > [ 2638.519743] firefox-bin/3399 is trying to acquire lock:
> > > [ 2638.519743] (&mm->mmap_sem){++++++}, at: [<ffffffff81548471>] do_page_fault+0x301/0x330
> > > [ 2638.519743]
> > > [ 2638.519743] but task is already holding lock:
> > > [ 2638.519743] (&sb->s_type->i_mutex_key#6){+.+.+.}, at: [<ffffffff810c2bd2>] generic_file_aio_write+0x52/0xd0
> > > [ 2638.519743]
> > > [ 2638.519743] which lock already depends on the new lock.
> > > [ 2638.519743]
> > > [ 2638.519743]
> > > [ 2638.519743] the existing dependency chain (in reverse order) is:
> > > [ 2638.519743]
> > > [ 2638.519743] -> #1 (&sb->s_type->i_mutex_key#6){+.+.+.}:
> > > [ 2638.519743] [<ffffffff8107c066>] __lock_acquire+0x12b6/0x1b40
> > > [ 2638.519743] [<ffffffff8107c9d1>] lock_acquire+0xe1/0x120
> > > [ 2638.519743] [<ffffffff8154328e>] mutex_lock_nested+0x5e/0x390
> > > [ 2638.519743] [<ffffffff811be15c>] nfs_revalidate_mapping+0xac/0x110 ==> takes i_mutex in nfs_invalidate_mapping()
> > > [ 2638.519743] [<ffffffff811bba25>] nfs_file_mmap+0x55/0x80
> > > [ 2638.519743] [<ffffffff810e2bb7>] mmap_region+0x427/0x600
> > > [ 2638.519743] [<ffffffff810e305e>] do_mmap_pgoff+0x2ce/0x3f0
> > > [ 2638.519743] [<ffffffff81010c26>] sys_mmap+0x106/0x130 ==> takes mmap_sem
> > > [ 2638.519743] [<ffffffff8100bf42>] system_call_fastpath+0x16/0x1b
> > > [ 2638.519743] [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > This is the faulty code path. mmap_sem is supposed to nest inside i_mutex.
>
> This could be a long stand bug: the nfs_revalidate_mapping() call was
> there in the very beginning of git history.
http://programming.kicks-ass.net/kernel-patches/mmap-vs-nfs/
next prev parent reply other threads:[~2009-06-18 16:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-18 2:32 NFS: possible circular locking i_mutex <> mmap_sem Wu Fengguang
2009-06-18 2:52 ` Andrew Morton
2009-06-18 3:02 ` Wu Fengguang
2009-06-18 16:48 ` Peter Zijlstra [this message]
2009-09-03 7:17 ` Wu Fengguang
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=1245343689.13761.23623.camel@twins \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mingo@elte.hu \
/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