From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DF889443 for ; Sun, 13 Aug 2023 21:31:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9FACC433C7; Sun, 13 Aug 2023 21:31:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1691962297; bh=mTDpp1s0ntZ4i1Msu9n6PTQL6FDXc4RcjLrdhpP3nKI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0jmp5FcFhvc84zEP5woKXipJ3mfDuJEGe7eSQ+qkNNhOeWnVF5uLXJNdfmpIEUfZR /neD6Q1rzIZ7fixzCAmDY4/Tf87VlAza7/YO6TWw5Pm7hDF+kmCoGh4A4Eacp2+oen tmFHh/cIA1VZSYKPm4moLuO0afw1KJrOHgKaGeJ0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Josef Bacik , Christoph Hellwig , David Sterba Subject: [PATCH 6.4 183/206] btrfs: dont stop integrity writeback too early Date: Sun, 13 Aug 2023 23:19:13 +0200 Message-ID: <20230813211730.258850922@linuxfoundation.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230813211724.969019629@linuxfoundation.org> References: <20230813211724.969019629@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christoph Hellwig commit effa24f689ce0948f68c754991a445a8d697d3a8 upstream. extent_write_cache_pages stops writing pages as soon as nr_to_write hits zero. That is the right thing for opportunistic writeback, but incorrect for data integrity writeback, which needs to ensure that no dirty pages are left in the range. Thus only stop the writeback for WB_SYNC_NONE if nr_to_write hits 0. This is a port of write_cache_pages changes in commit 05fe478dd04e ("mm: write_cache_pages integrity fix"). Note that I've only trigger the problem with other changes to the btrfs writeback code, but this condition seems worthwhile fixing anyway. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba [ updated comment ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent_io.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2181,11 +2181,12 @@ retry: } /* - * the filesystem may choose to bump up nr_to_write. + * The filesystem may choose to bump up nr_to_write. * We have to make sure to honor the new nr_to_write - * at any time + * at any time. */ - nr_to_write_done = wbc->nr_to_write <= 0; + nr_to_write_done = (wbc->sync_mode == WB_SYNC_NONE && + wbc->nr_to_write <= 0); } folio_batch_release(&fbatch); cond_resched();