Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3018153pxb; Mon, 18 Oct 2021 06:42:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzY+mBcOglQuwvAN2JneNPlgPpxHe72VlZApPxwryqpIh6CJ9lD3u/HsQJestH530CmJceT X-Received: by 2002:a17:90b:3844:: with SMTP id nl4mr47627607pjb.168.1634564545010; Mon, 18 Oct 2021 06:42:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634564545; cv=none; d=google.com; s=arc-20160816; b=pHAX71fo/GLlLxas2XvfeCoudpJZi3vJGhBGYHsrKHmQKcC/YL8CvqQAvTk3ukVrBr MyLbMGvJcIJ4Zgprm1oaKgtKynT33ERyAKTiziThlwllKKFSJrvS47CLE5IsF5BGPL6U ZrvFAfYiZAo+e9cfzQWhCcwYEVRXrogO4xP04Ed5+5JlwZ4QF0lrh/j9CRt50/fdYpKV 80o+BkHZ32VcZ8uwyCxT+awvrCHCzdq+RdB5uxnp5WVymlDWMoDt3aMQTlEgwuO578nv 9fLKrNEsr+J6fqtcKZpbRXKSkBMPQmF5C3/0aED7b4Fu/ek9KbFZ//VIXTOi65GTjk0t iH6w== 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=Ht+62NrgcL1qUvuxpdolrdhFhOZxWUOKahnOVO7MEeQ=; b=XYBb4Uh9pWXXYumsDszNgfFk11ORc5VNKI83H3xlAkZuy8vnixgjIBVK/ZiFKSjVwE DXIjMgH9arLRMVBKiI+9oI2Qz1ZxwN5vzBFzAq6oCGdpWKMQQx5nvZl3jD35Ow4HBxV7 HYI4nk47lPdH7c6zLBbA9GlPC21MgwLZ9yCYUcVEXcx2/Iy1iG9qEcBb09NyC3xry76g wlmdZfLRQbZ1nCZ3jn2kkX8wQ2MqRwezqY09tjaznwr1/KJXKTwFLhKxxIoDQfUR+q1E L2DHaEMA0NSNT4UEFfOMW3A/SS/5hCVsmWSqlQ/wpf9h5KX1Ztb2lMtr2M91nbH8c89h Zlzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DMqW3HCn; 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 g17si14910508pgk.528.2021.10.18.06.42.12; Mon, 18 Oct 2021 06:42:25 -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=DMqW3HCn; 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 S232839AbhJRNmS (ORCPT + 99 others); Mon, 18 Oct 2021 09:42:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:53502 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233466AbhJRNkQ (ORCPT ); Mon, 18 Oct 2021 09:40:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 14912613A0; Mon, 18 Oct 2021 13:33:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1634563990; bh=UcFL9DfXg+6mbtrclVkILyxxrPYNlGHcFAnxg0JclxY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DMqW3HCnM1jxgKDJcyWRa+ILiU8lDD0rbZGl453t8qWwpBKb6bj26O8bvgEwHziVn lIPOf4oZ7XCkkPNbXnbrGhzzef86IQ3rSWtw5J9s+ptIVapiLjUNn+C6qo67UvJOoV 2ahIPBLDQl1dM+YE4Gd/SU5rT3wwkiq85bJhurxo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nikolay Borisov , Filipe Manana , Josef Bacik , David Sterba Subject: [PATCH 5.10 024/103] btrfs: fix abort logic in btrfs_replace_file_extents Date: Mon, 18 Oct 2021 15:24:00 +0200 Message-Id: <20211018132335.521225185@linuxfoundation.org> X-Mailer: git-send-email 2.33.1 In-Reply-To: <20211018132334.702559133@linuxfoundation.org> References: <20211018132334.702559133@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 4afb912f439c4bc4e6a4f3e7547f2e69e354108f upstream. Error injection testing uncovered a case where we'd end up with a corrupt file system with a missing extent in the middle of a file. This occurs because the if statement to decide if we should abort is wrong. The only way we would abort in this case is if we got a ret != -EOPNOTSUPP and we called from the file clone code. However the prealloc code uses this path too. Instead we need to abort if there is an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only if we came from the clone file code. CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Nikolay Borisov Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/file.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2661,14 +2661,16 @@ int btrfs_replace_file_extents(struct in 1, 0, 0, NULL); if (ret != -ENOSPC) { /* - * When cloning we want to avoid transaction aborts when - * nothing was done and we are attempting to clone parts - * of inline extents, in such cases -EOPNOTSUPP is - * returned by __btrfs_drop_extents() without having - * changed anything in the file. + * The only time we don't want to abort is if we are + * attempting to clone a partial inline extent, in which + * case we'll get EOPNOTSUPP. However if we aren't + * clone we need to abort no matter what, because if we + * got EOPNOTSUPP via prealloc then we messed up and + * need to abort. */ - if (extent_info && !extent_info->is_new_extent && - ret && ret != -EOPNOTSUPP) + if (ret && + (ret != -EOPNOTSUPP || + (extent_info && extent_info->is_new_extent))) btrfs_abort_transaction(trans, ret); break; }