Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4368681pxj; Tue, 8 Jun 2021 12:35:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxz97W2BJMcABUUZZkjE/7gZ+0FggiCfStc+LpPPS9J9DNdjeBP2lby05rAW2oYzXaiIW2H X-Received: by 2002:a17:906:9715:: with SMTP id k21mr25215647ejx.553.1623180925117; Tue, 08 Jun 2021 12:35:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623180925; cv=none; d=google.com; s=arc-20160816; b=eM6FMVji6L+yk6n/f1YWoQdv5kxpkPkq+sypMjeVUf80s4WJGP04g5ymRIUCU2Yhe2 5xvcnbH0Y0ATtsjS40QKjRlyA4FjxlqMVYrGRvuFW+90SDxaetM2FBaXIMWalUo1WJC+ oBMWRUNAKgpP17IW7/ZM/OjZSKM0LRvaXQul2uT+DdpD3vCz2c9ZQ7DcRLtVdPlWFm8e GyawUuhEjWj0yN7afJ5uxll530uth5RsjfK8EnnAGpGRxoeHWlaaePr2KYWllTkeASH4 3q++vKs7KjWgZKSPh9zlZH0BLOv+oKabzu6QakSfpco97Gqb0v3F+D8EKPP6Zo5uOAnQ nnlg== 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=kIjOqBHSLQ45xZHNljj9z+eGyQZFBUU4bV8a/sRQEyU=; b=Q9DvapHxl/KigXYbGmMKVQb1vvJGb4cCnTawWKyavAD8KUcbP2kiKklSXnoKC4SUDN OEr4k39yQIqNKm3x0/EZqdMJ3EBOdrgLSwK/naFQAKPlgepDtBaMBQ2pbaWMwPRe0sWs KMTaoZF9EaE/iTtvtlWB4SYj97U1HZvG2w/+1mYre74v7+/5ka8/7u96Ke6F6BjQz/cb mRSQql4ktR4zWQZ9n5+oT5ZhJTfAsBD3i8y6AtMxcH5N07fjiJkkdrxSxnsEFieU2LqF DCCKvnSW2izL7hSI7bluRNS9o0l1SPLp1rjMfM05r+77sKvzJMqCJlkV5rSr4pwB8RNI 2+yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=h+j43rP3; 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 bx16si494684edb.256.2021.06.08.12.35.00; Tue, 08 Jun 2021 12:35: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=h+j43rP3; 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 S238617AbhFHTch (ORCPT + 99 others); Tue, 8 Jun 2021 15:32:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:36460 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237461AbhFHTQ4 (ORCPT ); Tue, 8 Jun 2021 15:16:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3699161970; Tue, 8 Jun 2021 18:51:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623178271; bh=/vS0BFpXf5eRM0ok6OPvRgxT8FL8iGC2B8FcFJtAcgI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h+j43rP3M1JN0Oqex3LbG4yZrXrt485eBGl5BUdX2fAoIk33Lqi8oWmct827H8PnO yC7jumU+SVbFTqJ1i7cXdhmWeNgHlsVTPfZyhWNYG7T3UOCBufK8/6QqrHnSe5KsE0 hMftQcgnhKVo/EnE85azHGfM3b/3iZk8r5yIb9U0= 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 140/161] btrfs: mark ordered extent and inode with error if we fail to finish Date: Tue, 8 Jun 2021 20:27:50 +0200 Message-Id: <20210608175950.178027783@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 d61bec08b904cf171835db98168f82bc338e92e4 upstream. While doing error injection testing I saw that sometimes we'd get an abort that wouldn't stop the current transaction commit from completing. This abort was coming from finish ordered IO, but at this point in the transaction commit we should have gotten an error and stopped. It turns out the abort came from finish ordered io while trying to write out the free space cache. It occurred to me that any failure inside of finish_ordered_io isn't actually raised to the person doing the writing, so we could have any number of failures in this path and think the ordered extent completed successfully and the inode was fine. Fix this by marking the ordered extent with BTRFS_ORDERED_IOERR, and marking the mapping of the inode with mapping_set_error, so any callers that simply call fdatawait will also get the error. With this we're seeing the IO error on the free space inode when we fail to do the finish_ordered_io. CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/inode.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3011,6 +3011,18 @@ out: if (ret || truncated) { u64 unwritten_start = start; + /* + * If we failed to finish this ordered extent for any reason we + * need to make sure BTRFS_ORDERED_IOERR is set on the ordered + * extent, and mark the inode with the error if it wasn't + * already set. Any error during writeback would have already + * set the mapping error, so we need to set it if we're the ones + * marking this ordered extent as failed. + */ + if (ret && !test_and_set_bit(BTRFS_ORDERED_IOERR, + &ordered_extent->flags)) + mapping_set_error(ordered_extent->inode->i_mapping, -EIO); + if (truncated) unwritten_start += logical_len; clear_extent_uptodate(io_tree, unwritten_start, end, NULL);