Re: Lockdep warning for iprune_mutex at shrink_icache_memory

[Dave Chinner]

On Tue, Nov 25, 2008 at 06:43:57AM -0500, Dan Noé wrote:
> I have experienced the following lockdep warning on 2.6.28-rc6.  I
> would be happy to help debug, but I don't know this section of code at
> all.
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.28-rc6git #1
> -------------------------------------------------------
> rsync/21485 is trying to acquire lock:
>  (iprune_mutex){--..}, at: [<ffffffff80310b14>]
> shrink_icache_memory+0x84/0x290
> 
> but task is already holding lock:
>  (&(&ip->i_iolock)->mr_lock){----}, at: [<ffffffffa01fcae5>]
> xfs_ilock+0x75/0xb0 [xfs]

False positive. memory reclaim can be invoked while we
are holding an inode lock, which means we go:

	xfs_ilock -> iprune_mutex

And when the inode shrinker reclaims a dirty xfs inode,
we go:

	iprune_mutex -> xfs_ilock

However, this cannot deadlock as the first case can
only occur with a referenced inode, and the second case
can only occur with an unreferenced inode. Hence we can
never get a situation where the inode being locked on
either side of the iprune_mutex is the same inode so
deadlock is impossible.

To avoid this false positive, either we need to turn off
lockdep checking on xfs inodes (not going to happen), or memory
reclaim needs to be able to tell lockdep that recursion on
filesystem lock classes may occur. Perhaps we can add a
simple annotation to the iprune mutex initialisation as well as
the xfs ilock initialisation to indicate that such recursion
is possible and allowed...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/