All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Miles Lane <miles.lane@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Dustin Kirkland <dustin.kirkland@gazzang.com>,
	ecryptfs@vger.kernel.org
Subject: Re: Linus GIT (3.3.0-rc6+) -- INFO: possible circular locking dependency detected
Date: Mon, 5 Mar 2012 15:46:22 -0600	[thread overview]
Message-ID: <20120305214621.GC29910@boyd> (raw)
In-Reply-To: <20120305213557.GO23916@ZenIV.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On 2012-03-05 21:35:58, Al Viro wrote:
> On Mon, Mar 05, 2012 at 01:23:34PM -0800, Andrew Morton wrote:
> > mmap_sem nests inside i_mutex.
> > 
> > On the path
> > 
> > 	munmap
> > 	->ecryptfs_vma_close
> > 	  ->filemap_write_and_wait
> > 	    ->generic_file_aio_write
> > 
> > we're taking i_mutex inside mmap_sem.  So the problem is triggered by
> > ecryptfs_vma_close() calling filemap_write_and_wait() inside munmap()'s
> > mmap_sem.
> > 
> > Question is: what did we recently change to cause this to happen?
> 
> AFAICS, it's commit 32001d6fe9ac6b0423e674a3093aa56740849f3b
> Author: Tyler Hicks <tyhicks@canonical.com>
> Date:   Mon Nov 21 17:31:29 2011 -0600
> 
>     eCryptfs: Flush file in vma close

Yes, it is definitely this commit. This is mainly what brought about my
patch to fix the incorrect logic around lockdep_set_class() in
lockdep_annotate_inode_mutex_key(). With that patch, I no longer saw
these lockdep warnings, so I wrote it off. Al has since made it clear
that this locking order is wrong.

This should fix itself when I revert
57db4e8d73ef2b5e94a3f412108dff2576670a8a. We'll no longer need this
flush in vma_close(), so 32001d6fe9ac6b0423e674a3093aa56740849f3b will
be reverted, too. I was planning on waiting until 3.4 to do all of that
since it will be a somewhat big change (even though it is mainly
reverting of patches).

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-03-05 21:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05 21:08 Linus GIT (3.3.0-rc6+) -- INFO: possible circular locking dependency detected Miles Lane
2012-03-05 21:23 ` Andrew Morton
2012-03-05 21:35   ` Al Viro
2012-03-05 21:46     ` Tyler Hicks [this message]
2012-03-05 21:33 ` Al Viro
2012-03-05 21:46 ` Ted Ts'o
2012-03-05 22:02   ` Ted Ts'o

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=20120305214621.GC29910@boyd \
    --to=tyhicks@canonical.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=dustin.kirkland@gazzang.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles.lane@gmail.com \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /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.