Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3029476pxb; Mon, 18 Oct 2021 06:56:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw48sp5UbapjFzy64g6IFj5wREDc2hYVzmSa0Xayc+m6vwa8UyL2+YcjIm6H5sMlXzmpRYm X-Received: by 2002:a05:6402:1157:: with SMTP id g23mr47527531edw.379.1634565395347; Mon, 18 Oct 2021 06:56:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634565395; cv=none; d=google.com; s=arc-20160816; b=VlavZdjcaUlTo/xfJKovP8j3WZi3wrKp8w4o9P3qquS7R9hnzaExpoDapqJMJGGGsi CTkGbIslUM3JkbqYpRda95CpVrTp8Xj0zgtbduw8EcQvHzvyG1/Sn34/c0I3Slt/KIwA hw2Pewd4Ectp1Qcz8FQA+sIDz0hkv0SrEcGFMuzaL0ja16jHH+tCYzxqXgx8ojay8ZCI xfUzh4z0eCK8WdYZXC5sa6I7G8ShYu+MK8HoRDCPDZqU3c8oIxoOs1j8qc9x8S1AHRU7 t0/mq7+Z0E6dHYYARDIs6kqRMNvA0bXa4lNaGe84slXp8JMJfS2YkiAX3K/IV5rvPBRf DutA== 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=9dzYkBdrxrDlY14zUU1UdM2aVsm5qX5Vz9yY5pi2uRk=; b=o+XdHqPsFXLgWbzoJIBpQQIqFFBcc1GvV6vXaZq/rl5Y5chmG+UUUxA0V30Ez7BbqC gDFVbfnoZAKwgee05eLuSzDt1SZn/ExVNp0uqBEq+NYgzXwxSipjTkwdqqvLULPgieK6 7YVny6dqVFGkYQepL6PZE/rjViymiRlv90DIxprHLjOp6vgV2cTGrwvEYjL+NaypRWGn aXL5htePI8uv7R6ux8QidBxmfMnT6UsgMpBuGYlbO5x6qYPonucOuVBG4xSt3uT2JMD1 OCdt/TZthA7NhDHAEfIACBlft0WbsefYBPmrPCuVixcG0Ewwdarm7V1HGi2PqBZRYQBq VqXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NiaW1gKl; 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 i22si35046609ejw.286.2021.10.18.06.56.11; Mon, 18 Oct 2021 06:56:35 -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=NiaW1gKl; 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 S234528AbhJRN4h (ORCPT + 99 others); Mon, 18 Oct 2021 09:56:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:56732 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233797AbhJRNyd (ORCPT ); Mon, 18 Oct 2021 09:54:33 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1782A613E6; Mon, 18 Oct 2021 13:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1634564383; bh=ilREWs/vTvF52vkD5GcR1vSJ9nn5JrHa7HpjlESQmSw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NiaW1gKlqKdiHqTxrL6dtvuYonukUC7w8UFXobTahZemP/G0nyyRyGMkTcG8nCBY1 abC08cy1l0BwHQDtIBxwH7Q8beo6gUwpAswuSue5dlO4E8UHtXpnFjP1dN/v/IHXYw GGAfXXOe38Vny9N6xbCKUrW9h+P0HHidOOcwHS2k= 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.14 035/151] btrfs: fix abort logic in btrfs_replace_file_extents Date: Mon, 18 Oct 2021 15:23:34 +0200 Message-Id: <20211018132341.834085864@linuxfoundation.org> X-Mailer: git-send-email 2.33.1 In-Reply-To: <20211018132340.682786018@linuxfoundation.org> References: <20211018132340.682786018@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 @@ -2691,14 +2691,16 @@ int btrfs_replace_file_extents(struct bt drop_args.bytes_found); 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; }