On Thu 06-09-12 06:39:21, Jeff Layton wrote:
> I got the following xfs-related lockdep pop on a 3.6.0-rc3+ kernel.
> I've been able to reproduce this twice now by doing a kernel build on
> xfs.
>
> The last commit from Linus' tree in this kernel is 9acb172. It also has
> a pile of my own and Al Viro's patches on top, but I don't think any of
> them would affect this. I should be able to test patches for this if
> you come up with one, but since I've only seen it twice I'm not sure
> how reproducible it is yet.
>
> [ 4175.887865]
> [ 4175.888032] =========================================================
> [ 4175.888032] [ INFO: possible irq lock inversion dependency detected ]
> [ 4175.888032] 3.6.0-rc3+ #11 Not tainted
> [ 4175.888032] ---------------------------------------------------------
> [ 4175.888032] kswapd0/41 just changed the state of lock:
> [ 4175.888032] (sb_internal){.+.+.?}, at: [<ffffffffa00f60ad>] xfs_trans_alloc+0x2d/0x50 [xfs]
> [ 4175.888032] but this lock took another, RECLAIM_FS-unsafe lock in the past:
> [ 4175.888032] (&(&ip->i_lock)->mr_lock/1){+.+.+.}
> [ 4175.888032]
> [ 4175.888032] and interrupts could create inverse lock ordering between them.
> [ 4175.888032]
> [ 4175.888032]
> [ 4175.888032] other info that might help us debug this:
> [ 4175.888032] Possible interrupt unsafe locking scenario:
> [ 4175.888032]
> [ 4175.888032] CPU0 CPU1
> [ 4175.888032] ---- ----
> [ 4175.888032] lock(&(&ip->i_lock)->mr_lock/1);
> [ 4175.888032] local_irq_disable();
> [ 4175.888032] lock(sb_internal);
> [ 4175.888032] lock(&(&ip->i_lock)->mr_lock/1);
> [ 4175.888032] <Interrupt>
> [ 4175.888032] lock(sb_internal);
> [ 4175.888032]
> [ 4175.888032] *** DEADLOCK ***
This is actually known and has nothing to do with fs freezeing AFAICT.
The problem is tham vm_map_ram() can do GFP_KERNEL allocation from deep
inside XFS and that can cause deadlocks...
It has been discussed here https://lkml.org/lkml/2012/6/13/582, but mm guys
have some issues with the simple solution.
Honza
--
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
