summaryrefslogtreecommitdiffstats
path: root/lib/atomic64_test.c
diff options
context:
space:
mode:
authorFilipe Manana <fdmanana@suse.com>2015-03-02 20:53:53 +0000
committerChris Mason <clm@fb.com>2015-03-26 17:55:51 -0700
commit2f1f465ae6da244099af55c066e5355abd8ff620 (patch)
tree05e245ff3ad099a59616f39710737119cb0442df /lib/atomic64_test.c
parent5cc2b17e80cf5770f2e585c2d90fd8af1b901258 (diff)
downloadop-kernel-dev-2f1f465ae6da244099af55c066e5355abd8ff620.zip
op-kernel-dev-2f1f465ae6da244099af55c066e5355abd8ff620.tar.gz
Btrfs: send, don't leave without decrementing clone root's send_progress
If the clone root was not readonly or the dead flag was set on it, we were leaving without decrementing the root's send_progress counter (and before we just incremented it). If a concurrent snapshot deletion was in progress and ended up being aborted, it would be impossible to later attempt to delete again the snapshot, since the root's send_in_progress counter could never go back to 0. We were also setting clone_sources_to_rollback to i + 1 too early - if we bailed out because the clone root we got is not readonly or flagged as dead we ended up later derreferencing a null pointer because we didn't assign the clone root to sctx->clone_roots[i].root: for (i = 0; sctx && i < clone_sources_to_rollback; i++) btrfs_root_dec_send_in_progress( sctx->clone_roots[i].root); So just don't increment the send_in_progress counter if the root is readonly or flagged as dead. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'lib/atomic64_test.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud