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@xxxxxxxxxxxxx> > 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:
signature.asc
Description: Digital signature
