]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
Btrfs: send, don't leave without decrementing clone root's send_progress
authorFilipe Manana <fdmanana@suse.com>
Mon, 2 Mar 2015 20:53:53 +0000 (20:53 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 23 Jun 2015 00:03:36 +0000 (17:03 -0700)
commit3a1e1ca1ba46fef415b663b44dae50cf1c0447f0
tree98b0eb87d85db9abb78f3fad8e80db6de5a53bd5
parent146a4565fa80cb586abcda5575922d5ac71162c9
Btrfs: send, don't leave without decrementing clone root's send_progress

commit 2f1f465ae6da244099af55c066e5355abd8ff620 upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/btrfs/send.c