Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4368733pxj; Tue, 8 Jun 2021 12:35:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxw0QB/Vyk9U7oxy1qTrqxcu0rU/Pg4OPYfuBAIJiCuNkz5/nQChXXmiVAB8MWWEiEa6MkZ X-Received: by 2002:a17:906:1982:: with SMTP id g2mr25463826ejd.184.1623180930552; Tue, 08 Jun 2021 12:35:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623180930; cv=none; d=google.com; s=arc-20160816; b=tz759qMb4i74HckQSSaAt/M6CW/AeH/VaGxe1mJV71ts6iwV8g55lRdJxcd2wgbq2s MzVcKWdivLqvhnD1AvM4pREEaVttkJxSrli8udhuzD4s78mHDiId9r0lEHq1KbGrIQrX 5DtO9OxkrGMdKITAY8Mz8SMxAYC3ILnUUpHUI9ElT1XSg8jF2o81jjVack6cNy14Yc9N LrhdDNxdlVtWcONkfNCUnpdCHqSqAZPH0cH546l1YIq1W7xJ07LtjQh1M2kwHdoEx/Ca cTQCoL2hcqTEqthh69eE/0Rf3O647BmIAWOxLzv1ahEMJHqqsQvFi7tfGqBBEYsQN65M 3m8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=xvWu2Obz2IEyuyajUQgAJk7oqfSqmV+4RR1LgAF1hIQ=; b=dSeya3s+ly4gpcVoPy5kmT0euaCyHknm4OIeOtE5dcdCiZI9FxOT9BLKSU5Q0eCrnH +v+0ApK/8xoRZIwkxLL+0WJlyyZo3xOV73+OzxJaryE8vLfHodhgZ5m2f+u9yLxTWzs+ kJi/viyKh1EP94KnHDkjxcab88E9rq5NQY2vfp73JrFONefkJOo+y2VlXRDxlTiboYeN S6Fb056xSdW6vfOlP2tVa1w0d5u2gXs2akoUjyiLpCkF7YWtd/ODXzyXtVQHlgbkKyrd b2ULgKxmcav2xpwKME0DBA1bUIXrUMuZJSXBXnI/FeK7DhVk2aPpq2+3jIvPsB9hz0Zo f5Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FPi24uCr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z11si495862ejl.136.2021.06.08.12.35.06; Tue, 08 Jun 2021 12:35:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FPi24uCr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238769AbhFHTdK (ORCPT + 99 others); Tue, 8 Jun 2021 15:33:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:37984 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237394AbhFHTSC (ORCPT ); Tue, 8 Jun 2021 15:18:02 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1B56761977; Tue, 8 Jun 2021 18:51:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623178287; bh=/zppk98WdwQocVwLh1eYbYTfhVTbwIBa2pMVSuX3L1U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FPi24uCrfwUBT0fYC8VZg4RC2NIajlvAwTM9q8chMhOMT3dU3aolOJD+/8erbc6AP 5OuIBhsHJ36z9bR4nAzl7G1fTL9ErlrYwnOxHzOhvAChg6EKA3gqU241TCu8otmmk7 8N++1N7ci59JjJSY+Srqs/tTeJixL+db5ZNcUVNI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , David Sterba Subject: [PATCH 5.12 146/161] btrfs: abort in rename_exchange if we fail to insert the second ref Date: Tue, 8 Jun 2021 20:27:56 +0200 Message-Id: <20210608175950.383075102@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210608175945.476074951@linuxfoundation.org> References: <20210608175945.476074951@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Josef Bacik commit dc09ef3562726cd520c8338c1640872a60187af5 upstream. Error injection stress uncovered a problem where we'd leave a dangling inode ref if we failed during a rename_exchange. This happens because we insert the inode ref for one side of the rename, and then for the other side. If this second inode ref insert fails we'll leave the first one dangling and leave a corrupt file system behind. Fix this by aborting if we did the insert for the first inode ref. CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/inode.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9088,6 +9088,7 @@ static int btrfs_rename_exchange(struct int ret2; bool root_log_pinned = false; bool dest_log_pinned = false; + bool need_abort = false; /* we only allow rename subvolume link between subvolumes */ if (old_ino != BTRFS_FIRST_FREE_OBJECTID && root != dest) @@ -9144,6 +9145,7 @@ static int btrfs_rename_exchange(struct old_idx); if (ret) goto out_fail; + need_abort = true; } /* And now for the dest. */ @@ -9159,8 +9161,11 @@ static int btrfs_rename_exchange(struct new_ino, btrfs_ino(BTRFS_I(old_dir)), new_idx); - if (ret) + if (ret) { + if (need_abort) + btrfs_abort_transaction(trans, ret); goto out_fail; + } } /* Update inode version and ctime/mtime. */