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
