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:14 PM, Wengang Wang wrote:
>
> 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 actually, there is a dm-thin on top of the loop device..

thanks,
wengang

>
> 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
>