On Wed, Oct 24, 2007 at 02:34:50PM +0200, Johannes Berg wrote:
> After rebooting my G5, updatedb started running at the end of which I
> found this lockdep report in my log:
> [ INFO: possible circular locking dependency detected ]
> 2.6.24-rc1-dirty #273
> -------------------------------------------------------
> sort/4261 is trying to acquire lock:
> (iprune_mutex){--..}, at: [<c0000000000f8c74>]
> .shrink_icache_memory+0x80/0x2d4
>
> but task is already holding lock:
> (&(&ip->i_iolock)->mr_lock){----}, at: [<c0000000001c9ce8>]
> .xfs_ilock+0x38/0xb8
>
> which lock already depends on the new lock.
Not a bug.
It's a know issue with memory reclaim and filesystem writeback - if
we trigger reclaim within the filesystem, we can invert the locking
heirachy that lockdep sees. This particular case cannot possibly deadlock
as the inode we already hold locked cannot be on the unused inode
list that shrink_icache_memory() is scanning.
AFAIA, there are no existing annotations we can add to prevent these
false reports...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|