From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap1.codethink.co.uk ([176.9.8.82]:46626 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933955AbeFQQ0n (ORCPT ); Sun, 17 Jun 2018 12:26:43 -0400 Message-ID: <1529252797.2289.206.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 181/268] Btrfs: fix copy_items() return value when logging an inode From: Ben Hutchings To: Filipe Manana , David Sterba , Sasha Levin Cc: stable@vger.kernel.org, Greg Kroah-Hartman , LKML Date: Sun, 17 Jun 2018 17:26:37 +0100 In-Reply-To: <20180528100222.864980245@linuxfoundation.org> References: <20180528100202.045206534@linuxfoundation.org> <20180528100222.864980245@linuxfoundation.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > ------------------ > > From: Filipe Manana > > [ Upstream commit 8434ec46c6e3232cebc25a910363b29f5c617820 ] Should stable branches also get a backport of commit 4ee3fad34a9cc2cf33303dfbd0cf554248651c86? It looks like 4.4 and 4.9 would need a minor change (inode->root to BTRFS_I(inode)->root) but I don't know whether that's really sufficient. Ben. > When logging an inode, at tree-log.c:copy_items(), if we call > btrfs_next_leaf() at the loop which checks for the need to log holes, we > need to make sure copy_items() returns the value 1 to its caller and > not 0 (on success). This is because the path the caller passed was > released and is now different from what is was before, and the caller > expects a return value of 0 to mean both success and that the path > has not changed, while a return value of 1 means both success and > signals the caller that it can not reuse the path, it has to perform > another tree search. > > Even though this is a case that should not be triggered on normal > circumstances or very rare at least, its consequences can be very > unpredictable (especially when replaying a log tree). > > Fixes: 16e7549f045d ("Btrfs: incompatible format change to remove hole extents") > Signed-off-by: Filipe Manana > Signed-off-by: David Sterba > Signed-off-by: Sasha Levin > Signed-off-by: Greg Kroah-Hartman > --- >  fs/btrfs/tree-log.c |    1 + >  1 file changed, 1 insertion(+) > > --- a/fs/btrfs/tree-log.c > +++ b/fs/btrfs/tree-log.c > @@ -3835,6 +3835,7 @@ fill_holes: >   ASSERT(ret == 0); >   src = src_path->nodes[0]; >   i = 0; > + need_find_last_extent = true; >   } >   >   btrfs_item_key_to_cpu(src, &key, i); -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom