…laim

Reclaiming blocks allocated to an inode's CoW fork can happen as part of
inode reclamation, which in turn can be triggered by memory reclaim.
Therefore, we cannot let the transaction allocation recurse into fs
reclaim.  This manifests as lockdep warnings such as:

======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc1 #1 Not tainted
------------------------------------------------------
xfs_scrub/1344 is trying to acquire lock:
 (fs_reclaim){+.+.}, at: [<ffffffff811b2b75>] fs_reclaim_acquire.part.75+0x5/0x30

but task is already holding lock:
 (sb_internal){.+.+}, at: [<ffffffffa015e65b>] xfs_trans_alloc+0xeb/0x130 [xfs]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (sb_internal){.+.+}:
       lock_acquire+0xab/0x200
       __sb_start_write+0xbc/0x200
       xfs_trans_alloc+0xeb/0x130 [xfs]
       xfs_reflink_cancel_cow_range+0x8e/0x3d0 [xfs]
       xfs_fs_destroy_inode+0x22f/0x350 [xfs]
       dispose_list+0x48/0x70
       prune_icache_sb+0x42/0x50
       super_cache_scan+0x13b/0x190
       shrink_slab.constprop.79+0x212/0x5d0
       shrink_node+0x5f/0x190
       do_try_to_free_pages+0xd8/0x2d0
       try_to_free_pages+0xf1/0x370
       __alloc_pages_slowpath+0x445/0x10d0
       __alloc_pages_nodemask+0x2c4/0x340
       khugepaged+0xb38/0x2510
       kthread+0x148/0x180
       ret_from_fork+0x2a/0x40

-> #0 (fs_reclaim){+.+.}:
       __lock_acquire+0x10bf/0x1110
       lock_acquire+0xab/0x200
       fs_reclaim_acquire.part.75+0x29/0x30
       kmem_cache_alloc+0x29/0x2d0
       kmem_zone_alloc+0x83/0x100 [xfs]
       xfs_trans_alloc+0x68/0x130 [xfs]
       xfs_reflink_cancel_cow_range+0x8e/0x3d0 [xfs]
       xfs_fs_destroy_inode+0x22f/0x350 [xfs]
       xfs_bulkstat_one_int+0x262/0x480 [xfs]
       xfs_bulkstat_one+0x16/0x20 [xfs]
       xfs_bulkstat+0x4c5/0x6b0 [xfs]
       xfs_ioc_bulkstat+0xee/0x190 [xfs]
       xfs_file_ioctl+0x41b/0xd30 [xfs]
       do_vfs_ioctl+0x8f/0x6f0
       SyS_ioctl+0x3b/0x70
       entry_SYSCALL_64_fastpath+0x1f/0xbe

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>