On Thu, May 15, 2008 at 09:45:55PM +0400, Alexander Beregalov wrote:
> 2008/5/12 David Chinner <dgc@xxxxxxx>:
> > 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
|