From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754157Ab1HWLtl (ORCPT ); Tue, 23 Aug 2011 07:49:41 -0400 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:2408 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706Ab1HWLtf (ORCPT ); Tue, 23 Aug 2011 07:49:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkDAKKQU055LIxDgWdsb2JhbABBqBsVAQEWJiWBQAEBBScLASMjEAgDDgouFA0YAyETh3W5Lw6FW18EnRCHFQ Date: Tue, 23 Aug 2011 21:49:31 +1000 From: Dave Chinner To: Josh Boyer Cc: Miles Lane , LKML , "Theodore Ts'o" , Andreas Dilger Subject: Re: 3.1.0-rc3 -- INFO: possible circular locking dependency detected Message-ID: <20110823114931.GC3162@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 23, 2011 at 07:35:00AM -0400, Josh Boyer wrote: > On Tue, Aug 23, 2011 at 12:39 AM, Miles Lane wrote: > > [ INFO: possible circular locking dependency detected ] > > 3.1.0-rc3 #2 > > ------------------------------------------------------- > > dconf-service/1836 is trying to acquire lock: > >  (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [] > > ext4_evict_inode+0x88/0x32b > > > >  but task is already holding lock: > >  (&mm->mmap_sem){++++++}, at: [] sys_munmap+0x36/0x5b > > > > which lock already depends on the new lock. > > > > the existing dependency chain (in reverse order) is: > > > > -> #1 (&mm->mmap_sem){++++++}: > >       [] lock_acquire+0x129/0x14e > >       [] might_fault+0x68/0x8b > >       [] filldir+0x6a/0xc2 > >       [] call_filldir+0x91/0xb8 > >       [] ext4_readdir+0x1af/0x510 > >       [] vfs_readdir+0x76/0xac > >       [] sys_getdents+0x79/0xc9 > >       [] system_call_fastpath+0x16/0x1b > > > > -> #0 (&sb->s_type->i_mutex_key#12){+.+.+.}: > >       [] __lock_acquire+0xa5e/0xd52 > >       [] lock_acquire+0x129/0x14e > >       [] __mutex_lock_common+0x64/0x413 > >       [] mutex_lock_nested+0x16/0x18 > >       [] ext4_evict_inode+0x88/0x32b > >       [] evict+0x94/0x14e > >       [] iput+0x18c/0x195 > >       [] dentry_kill+0x11e/0x140 > >       [] dput+0xd4/0xe4 > >       [] fput+0x1a5/0x1bd > >       [] remove_vma+0x37/0x5f > >       [] do_munmap+0x2ed/0x306 > >       [] sys_munmap+0x44/0x5b > >       [] system_call_fastpath+0x16/0x1b > > > > other info that might help us debug this: > > > >  Possible unsafe locking scenario: > > > >       CPU0                    CPU1 > >       ----                    ---- > >  lock(&mm->mmap_sem); > >                               lock(&sb->s_type->i_mutex_key); > >                               lock(&mm->mmap_sem); > >  lock(&sb->s_type->i_mutex_key); > > > >  *** DEADLOCK *** > > This one was reported yesterday: https://lkml.org/lkml/2011/8/21/163 > and we're hoping Ted (or someone else from the ext4 camp) can comment > on why ext4_evict_inode is holding i_mutex. Actually, the problem has nothing to do with ext4. the problem is that remove_vma() is holding the mmap_sem while calling fput(). The correct locking order is i_mutex->mmap_sem, as documented in mm/filemap.c: * ->i_mutex (generic_file_buffered_write) * ->mmap_sem (fault_in_pages_readable->do_page_fault) The way remove_vma() calls fput() also triggers lockdep reports in XFS and it will do so with any filesystem that takes an inode specific lock in it's evict() processing. IOWs, remove_vma() needs fixing, not ext4.... Cheers, Dave. -- Dave Chinner david@fromorbit.com