From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cantor2.suse.de ([195.135.220.15]:42545 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbbCIQpx (ORCPT ); Mon, 9 Mar 2015 12:45:53 -0400 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 191BBAAC8 for ; Mon, 9 Mar 2015 16:45:52 +0000 (UTC) Date: Mon, 9 Mar 2015 17:45:51 +0100 From: David Sterba To: Filipe Manana Cc: linux-btrfs@vger.kernel.org Subject: Re: [PATCH 2/2] Btrfs: send, don't leave without decrementing clone root's send_progress Message-ID: <20150309164551.GH5841@twin.jikos.cz> Reply-To: dsterba@suse.cz References: <1425329633-5059-1-git-send-email-fdmanana@suse.com> <1425329633-5059-2-git-send-email-fdmanana@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1425329633-5059-2-git-send-email-fdmanana@suse.com> Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Mon, Mar 02, 2015 at 08:53:53PM +0000, Filipe Manana wrote: > 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 Reviewed-by: David Sterba