Re: xfs freeze annotation problem on 3.6.0-rc3+ kernel

[Jan Kara <jack@suse.cz>]

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