From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2125EB64D9 for ; Sun, 2 Jul 2023 19:43:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231846AbjGBTnO (ORCPT ); Sun, 2 Jul 2023 15:43:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231835AbjGBTm3 (ORCPT ); Sun, 2 Jul 2023 15:42:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91E0D1994; Sun, 2 Jul 2023 12:41:44 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AD25660CE8; Sun, 2 Jul 2023 19:41:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E676C433C9; Sun, 2 Jul 2023 19:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688326874; bh=6aBSJR5xa6e4dnzZV1ITCtWICxobyg4lIS0+M9oh1II=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aqd9wnXDFzgE4/Pht4bII8AW8AYBBbKjo6Vc6eWp1ko8Hoifcq6NNEKWvyZhh2ZU5 QCBqZSUKUVHXFurLNp2HsWFCg+jO0VSICwhICA01+IuKSJBvXNE7xq+J/Y/CtzcJb+ C7NXs6xlDKOE7/nXCLtJbsOgnT3S7d361l/Q74ydvbR1M+U6Kadd2b4FYz2mwfRXsq G6gAVocU5KWvYV9MYE4OI2sJOp4W5oCQsO1EqWGGTrxyvgRvULEjCmTYjDvX8W12nu zyt7mzBlmtm/Id/CtPPtpEmUirZaL7Icm8LMuNkUWAoWqUMd5i0XR6TIHiTLYTlqO5 FANiTFpwoH7Sg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christoph Hellwig , Josef Bacik , David Sterba , Sasha Levin , clm@fb.com, linux-btrfs@vger.kernel.org Subject: [PATCH AUTOSEL 6.3 12/14] btrfs: don't check PageError in __extent_writepage Date: Sun, 2 Jul 2023 15:40:51 -0400 Message-Id: <20230702194053.1777356-12-sashal@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230702194053.1777356-1-sashal@kernel.org> References: <20230702194053.1777356-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.3.11 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Christoph Hellwig [ Upstream commit 3e92499e3b004baffb479d61e191b41b604ece9a ] __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context. Reviewed-by: Josef Bacik Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/extent_io.c | 33 +-------------------------------- 1 file changed, 1 insertion(+), 32 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 40300e8e5f99c..9202339ca8288 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -1739,38 +1739,7 @@ static int __extent_writepage(struct page *page, struct writeback_control *wbc, set_page_writeback(page); end_page_writeback(page); } - /* - * Here we used to have a check for PageError() and then set @ret and - * call end_extent_writepage(). - * - * But in fact setting @ret here will cause different error paths - * between subpage and regular sectorsize. - * - * For regular page size, we never submit current page, but only add - * current page to current bio. - * The bio submission can only happen in next page. - * Thus if we hit the PageError() branch, @ret is already set to - * non-zero value and will not get updated for regular sectorsize. - * - * But for subpage case, it's possible we submit part of current page, - * thus can get PageError() set by submitted bio of the same page, - * while our @ret is still 0. - * - * So here we unify the behavior and don't set @ret. - * Error can still be properly passed to higher layer as page will - * be set error, here we just don't handle the IO failure. - * - * NOTE: This is just a hotfix for subpage. - * The root fix will be properly ending ordered extent when we hit - * an error during writeback. - * - * But that needs a bigger refactoring, as we not only need to grab the - * submitted OE, but also need to know exactly at which bytenr we hit - * the error. - * Currently the full page based __extent_writepage_io() is not - * capable of that. - */ - if (PageError(page)) + if (ret) end_extent_writepage(page, ret, page_start, page_end); if (bio_ctrl->extent_locked) { /* -- 2.39.2