]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs: queue deferred rmap ops for cow staging extent alloc/free in the right order
authorDarrick J. Wong <darrick.wong@oracle.com>
Wed, 3 Jan 2018 19:42:10 +0000 (13:42 -0600)
committerEric Sandeen <sandeen@redhat.com>
Wed, 3 Jan 2018 19:42:10 +0000 (13:42 -0600)
commita44b23a0eb0a2300a8f39a6a4eb71c272af9788c
tree60e641039614b790bd394d4f6ecae9167235d653
parent6428e6c79cebc6b83c40ca18ffe7e0b58aa048ce
xfs: queue deferred rmap ops for cow staging extent alloc/free in the right order

Source kernel commit: 0525e952dcceb9fc947c6d395de7f72220c7d081

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>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
libxfs/xfs_refcount.c