Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3426585imu; Sun, 11 Nov 2018 14:50:37 -0800 (PST) X-Google-Smtp-Source: AJdET5dCg6vby2x4TcHfPszzMVErCpNOfWvSsX2Xu/4NrLyAviNkd23H4opSyUEafFx2deIMb1Fq X-Received: by 2002:a17:902:5a03:: with SMTP id q3-v6mr129688pli.186.1541976637068; Sun, 11 Nov 2018 14:50:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541976637; cv=none; d=google.com; s=arc-20160816; b=zM1FSIbQN45mRb/aBhzeTxKGFrV1MFeOUqXoGv3qlG2j2sU+OSpmamvjNckN5d65i1 KzuPR4rmAfDEZMKa/KwbIxVG7O8KiSyid1HMGmm86z96MqHRQxUsPJXkqCntwU5eEYrB eUACtRKKw9UkLOEm7jqSPmahXcMJG/V8iYSAOdaXfWJJEuMIqj11zQtwJgeqstLNi8oH wtyZLYsKIyDdKxsWH8/AbV4wv3Cb4JPDSUXeUTApps3eVuEIJJZXen2YZcMoTJsjlPtQ WHkYfZgQ1gjYTiRwvXZmtrobq5Zb/2Ceuf7Y3+4mauAyMzwCFRyQLNKMw5UfOz1vk5Gb Z8gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=88d//EnQT4fyCiZb1YRSsXNpaIX9S01PBejGsywCkBc=; b=tvn/aSa1HuWRZsTa/aMizTTMJIa1scXYQ6X69SqpyMj941P4YoMljTToQF51gusS9i N9TCnDQLfXaznI2W4tvZDqnE5/yr09bnhT0zD0rJluPIHs5861FSmj4wAYXk92bV4LUF bAumCY49aP7tuqOHuh5rn1sluBrrNZltt5+RjT7uVFkGyOptt4znH4tgmdi0Hc41e+dz PqDs2/1w1hY/GQT3x9FnTvsi/68YQ/aOfqZ6u+q9+R6k8LPFxTTbkrYhQUiVeaT0Fhiw rW62khEjYKbpFLaQvOXglltMXREIgu1yjHoPh2vSM6PWxaM2fKONp4TDCrxOyolm9+59 ftyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uJuJkzF5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d3si1960158pgu.437.2018.11.11.14.50.22; Sun, 11 Nov 2018 14:50:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uJuJkzF5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404271AbeKLIXM (ORCPT + 99 others); Mon, 12 Nov 2018 03:23:12 -0500 Received: from mail.kernel.org ([198.145.29.99]:54772 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404245AbeKLIXK (ORCPT ); Mon, 12 Nov 2018 03:23:10 -0500 Received: from localhost (unknown [206.108.79.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 45BC621780; Sun, 11 Nov 2018 22:33:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541975593; bh=UtazJZIprkXaZwXRkis0NoTvM1b4L/ZWrAh0DZGoiSw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uJuJkzF5+HVMzDh7XGPk9blcaSZCDD6gHJdgZHjR/lxo1fJQt0C5uFK+2YVseTpsE dbzXwdjZn/npnsUJ3Jfa+96cNxiTsfrV/pAeIwPtqHb13oHqiDnvadzJdttx0TdbTB 6V1nGDNfqWEyls7PIpoKkywVNcDD4GFhC2sl2ylQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba Subject: [PATCH 4.14 209/222] Btrfs: fix wrong dentries after fsync of file that got its parent replaced Date: Sun, 11 Nov 2018 14:25:06 -0800 Message-Id: <20181111221705.296543173@linuxfoundation.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181111221647.665769131@linuxfoundation.org> References: <20181111221647.665769131@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Filipe Manana commit 0f375eed92b5a407657532637ed9652611a682f5 upstream. In a scenario like the following: mkdir /mnt/A # inode 258 mkdir /mnt/B # inode 259 touch /mnt/B/bar # inode 260 sync mv /mnt/B/bar /mnt/A/bar mv -T /mnt/A /mnt/B fsync /mnt/B/bar After replaying the log we end up with file bar having 2 hard links, both with the name 'bar' and one in the directory with inode number 258 and the other in the directory with inode number 259. Also, we end up with the directory inode 259 still existing and with the directory inode 258 still named as 'A', instead of 'B'. In this scenario, file 'bar' should only have one hard link, located at directory inode 258, the directory inode 259 should not exist anymore and the name for directory inode 258 should be 'B'. This incorrect behaviour happens because when attempting to log the old parents of an inode, we skip any parents that no longer exist. Fix this by forcing a full commit if an old parent no longer exists. A test case for fstests follows soon. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/tree-log.c | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -5583,9 +5583,33 @@ static int btrfs_log_all_parents(struct dir_inode = btrfs_iget(fs_info->sb, &inode_key, root, NULL); - /* If parent inode was deleted, skip it. */ - if (IS_ERR(dir_inode)) - continue; + /* + * If the parent inode was deleted, return an error to + * fallback to a transaction commit. This is to prevent + * getting an inode that was moved from one parent A to + * a parent B, got its former parent A deleted and then + * it got fsync'ed, from existing at both parents after + * a log replay (and the old parent still existing). + * Example: + * + * mkdir /mnt/A + * mkdir /mnt/B + * touch /mnt/B/bar + * sync + * mv /mnt/B/bar /mnt/A/bar + * mv -T /mnt/A /mnt/B + * fsync /mnt/B/bar + * + * + * If we ignore the old parent B which got deleted, + * after a log replay we would have file bar linked + * at both parents and the old parent B would still + * exist. + */ + if (IS_ERR(dir_inode)) { + ret = PTR_ERR(dir_inode); + goto out; + } if (ctx) ctx->log_new_dentries = false;