Re: [PATCH] xfs: don't change to infinate lock to avoid dead lock

[Wengang Wang <wen.gang.wang@oracle.com>]

On 4/23/20 4:05 PM, Dave Chinner wrote:
> On Thu, Apr 23, 2020 at 10:23:25AM -0700, Wengang Wang wrote:
>> xfs_reclaim_inodes_ag() do infinate locking on pag_ici_reclaim_lock at the
>> 2nd round of walking of all AGs when SYNC_TRYLOCK is set (conditionally).
>> That causes dead lock in a special situation:
>>
>> 1) In a heavy memory load environment, process A is doing direct memory
>> reclaiming waiting for xfs_inode.i_pincount to be cleared while holding
>> mutex lock pag_ici_reclaim_lock.
>>
>> 2) i_pincount is increased by adding the xfs_inode to journal transection,
>> and it's expected to be decreased when the transection related IO is done.
>> Step 1) happens after i_pincount is increased and before truansection IO is
>> issued.
>>
>> 3) Now the transection IO is issued by process B. In the IO path (IO could
>> be more complex than you think), memory allocation and memory direct
>> reclaiming happened too.
> Sure, but IO path allocations are done under GFP_NOIO context, which
> means IO path allocations can't recurse back into filesystem reclaim
> via direct reclaim. Hence there should be no way for an IO path
> allocation to block on XFS inode reclaim and hence there's no
> possible deadlock here...
>
> IOWs, I don't think this is the deadlock you are looking for. Do you
> have a lockdep report or some other set of stack traces that lead
> you to this point?

As I mentioned, the IO path can be more complex than you think.

The real case I hit is that the process A is waiting for inode unpin on 
XFS A which is a loop device backed mount.

And the backing file is from a different (X)FS B mount. So the IO is 
going through loop device, (direct) writes to (X)FS B.

The (direct) writes to (X)FS B do memory allocations and then memory 
direct reclaims...

thanks,
wengang