summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_fsops.c
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2017-12-07 19:07:03 -0800
committerDarrick J. Wong <darrick.wong@oracle.com>2017-12-21 08:48:38 -0800
commit0525e952dcceb9fc947c6d395de7f72220c7d081 (patch)
treee0061543649ee3cc964d228eaaa7cf4e5709c3f0 /fs/xfs/xfs_fsops.c
parent86d692bfad1b0097fa866f5fcfa5f5adf4cd82e8 (diff)
downloadlinux-0525e952dcceb9fc947c6d395de7f72220c7d081.tar.bz2
xfs: queue deferred rmap ops for cow staging extent alloc/free in the right order
Under the deferred rmap operation scheme, there's a certain order in which the rmap deferred ops have to be queued to maintain integrity during log replay. For alloc/map operations that order is cui -> rui; for free/unmap operations that order is cui -> rui -> efi. However, the initial refcount code got the ordering wrong in the free side of things because it queued refcount free op and an EFI and the refcount free op queued a rmap free op, resulting in the order cui -> efi -> rui. If we fail before the efd finishes, the efi recovery will try to do a wildcard rmap removal and the subsequent rui will fail to find the rmap and blow up. This didn't ever happen due to other screws up in handling unknown owner rmap removals, but those other screw ups broke recovery in other ways, so fix the ordering to follow the intended rules. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'fs/xfs/xfs_fsops.c')
0 files changed, 0 insertions, 0 deletions