lkml.org 
[lkml]   [2008]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.26-rc1: possible circular locking dependency with xfs filesystem
On Thu, May 15, 2008 at 09:45:55PM +0400, Alexander Beregalov wrote:
> 2008/5/12 David Chinner <dgc@sgi.com>:
> > On Sun, May 11, 2008 at 09:18:07AM +0530, Kamalesh Babulal wrote:
> >> Kamalesh Babulal wrote:
> >> > Adding the cc to kernel-list, Ingo Molnar and Peter Zijlstra
> >> >
> >> > Alexander Beregalov wrote:
> >> >> [ INFO: possible circular locking dependency detected ]
> >> >> 2.6.26-rc1-00279-g28a4acb #13
> >> >> -------------------------------------------------------
> >> >> nfsd/3087 is trying to acquire lock:
> >> >> (iprune_mutex){--..}, at: [<c016f947>] shrink_icache_memory+0x38/0x19b
> >> >>
> >> >> but task is already holding lock:
> >> >> (&(&ip->i_iolock)->mr_lock){----}, at: [<c0210b83>] xfs_ilock+0xa2/0xd6

[snip]

> > Oh, yeah, that. Direct inode reclaim through memory pressure.
> >
> > Effectively memory reclaim inverts locking order w.r.t. iprune_mutex
> > when it recurses into the filesystem. False positive - can never
> > cause a deadlock on XFS. Can't be solved from the XFS side of things
> > without effectively turning off lockdep checking for xfs inode
> > locking.
> Yes, it is not a deadlock, but machine hangs for few seconds.
> It still happens about once a day for me. Every kernel report looks
> similar to the above.

That hang is just memory reclaim running, I think you'll find.
It can take some time for reclaim to find pages to use, and meanwhile
everything in the machine will back up behind it....

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group


\
 
 \ /
  Last update: 2008-05-16 00:31    [W:0.034 / U:2.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site