From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay1.corp.sgi.com (Postfix) with SMTP id 31A1C8F8117 for ; Thu, 15 May 2008 15:08:12 -0700 (PDT) Date: Fri, 16 May 2008 08:07:57 +1000 From: David Chinner Subject: Re: [xfs-masters] lockdep report (2.6.26-rc2) Message-ID: <20080515220757.GS155679365@sgi.com> References: <1210858590.3900.1.camel@johannes.berg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1210858590.3900.1.camel@johannes.berg> Sender: owner-linux-mm@kvack.org Return-Path: To: xfs-masters@oss.sgi.com Cc: xfs , linux-mm List-ID: On Thu, May 15, 2008 at 03:36:30PM +0200, Johannes Berg wrote: > On 64-bit powerpc, the extra version is just wireless patches. > [ 1533.995346] > [ 1533.995351] ======================================================= > [ 1533.995371] [ INFO: possible circular locking dependency detected ] > [ 1533.995379] 2.6.26-rc2-wl-07523-g4079cb5-dirty #35 > [ 1533.995385] ------------------------------------------------------- > [ 1533.995393] nautilus/4053 is trying to acquire lock: > [ 1533.995401] (&mm->mmap_sem){----}, at: [] .do_page_fault+0x1fc/0x5b0 > [ 1533.995431] > [ 1533.995433] but task is already holding lock: > [ 1533.995441] (&(&ip->i_iolock)->mr_lock){----}, at: [] .xfs_ilock+0x54/0xa8 > [ 1533.995470] > [ 1533.995472] which lock already depends on the new lock. > [ 1533.995474] > [ 1533.995481] > [ 1533.995482] the existing dependency chain (in reverse order) is: > [ 1533.995489] > [ 1533.995491] -> #1 (&(&ip->i_iolock)->mr_lock){----}: > [ 1533.995511] [] .__lock_acquire+0xd74/0xfdc > [ 1533.995553] [] .lock_acquire+0xc4/0x110 > [ 1533.995591] [] .down_write_nested+0x74/0x114 > [ 1533.995630] [] .xfs_ilock+0x38/0xa8 > [ 1533.995667] [] .xfs_free_eofblocks+0x158/0x2a8 > [ 1533.995703] [] .xfs_release+0x1a4/0x1d4 > [ 1533.995741] [] .xfs_file_release+0x1c/0x3c > [ 1533.995779] [] .__fput+0x118/0x204 > [ 1533.995814] [] .fput+0x3c/0x50 > [ 1533.995850] [] .remove_vma+0x84/0xd8 > [ 1533.995886] [] .do_munmap+0x2f4/0x344 > [ 1533.995923] [] .sys_munmap+0x5c/0x94 > [ 1533.995958] [] syscall_exit+0x0/0x40 > [ 1533.995996] > [ 1533.995997] -> #0 (&mm->mmap_sem){----}: > [ 1533.996014] [] .__lock_acquire+0xc74/0xfdc > [ 1533.996049] [] .lock_acquire+0xc4/0x110 > [ 1533.996084] [] .down_read+0x60/0x114 > [ 1533.996121] [] .do_page_fault+0x1fc/0x5b0 > [ 1533.996157] [] handle_page_fault+0x20/0x5c > [ 1533.996192] [] .file_read_actor+0x7c/0x208 > [ 1533.996230] [] .generic_file_aio_read+0x2c8/0x5e8 > [ 1533.996265] [] .xfs_read+0x1c0/0x278 > [ 1533.996299] [] .xfs_file_aio_read+0x6c/0x84 > [ 1533.996335] [] .do_sync_read+0xd4/0x13c > [ 1533.996372] [] .vfs_read+0xd8/0x1b0 > [ 1533.996408] [] .sys_read+0x5c/0xa8 > [ 1533.996443] [] syscall_exit+0x0/0x40 > [ 1533.996479] > [ 1533.996480] other info that might help us debug this: Fundamentally - if a filesystem takes the same lock in ->file_aio_read as it does in ->release, then this will happen. The lock outside the filesystem (the mmap lock) is can be taken before we enter the filesystem or while we are inside a filesystem method reading or writing data. In this case, XFS uses the iolock to serialise I/O vs truncate. We hold the iolock shared over read I/O, and exclusive when we do a truncate. The truncate in this case is a truncate of blocks past EOF on ->release. Whether this can deadlock depends on whether these two things can happen on the same mmap->sem and same inode at the same time. I know they can happen onteh same inode at the same time, but can this happen on the same mmap->sem? VM gurus? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org