On Sat, May 26, 2007 at 02:29:48AM +0400, Alexey Dobriyan wrote:
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.22-rc2 #1
> -------------------------------------------------------
> mplayer/16241 is trying to acquire lock:
> (iprune_mutex){--..}, at: [<c0158322>] shrink_icache_memory+0x2e/0x16b
>
> but task is already holding lock:
> (&(&ip->i_iolock)->mr_lock){----}, at: [<c01fc4d8>] xfs_ilock+0x44/0x86
>
> which lock already depends on the new lock.
Not A Bug, AFAICT. The locking order on memory reclaim is normally
iprune_mutex - xfs_inode->i_iolock.
But in this case, because the memory reclaim triggered from
blockable_page_cache_readahead(), we've got:
xfs_inode->i_iolock - iprune_mutex - some other xfs_inode->i_iolock
triggering a warning. This can never produce circular deadlocks
as the inodes being pruned have zero references, and the inode we
already hold the lock on has >=1 reference so the pruning code
won't every see it.
So, false positive. What lockdep annotation are we supposed to
use to fix this sort of thing?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
