From: Greg Kroah-Hartman Date: Sat, 12 Aug 2023 21:31:42 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.14.323~27 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0151803a505f3acbbd00f272f74209ba0ba9928d;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: btrfs-don-t-stop-integrity-writeback-too-early.patch btrfs-don-t-wait-for-writeback-on-clean-pages-in-extent_write_cache_pages.patch btrfs-set-cache_block_group_error-if-we-find-an-error.patch --- diff --git a/queue-5.4/btrfs-don-t-stop-integrity-writeback-too-early.patch b/queue-5.4/btrfs-don-t-stop-integrity-writeback-too-early.patch new file mode 100644 index 00000000000..1b9f9a11418 --- /dev/null +++ b/queue-5.4/btrfs-don-t-stop-integrity-writeback-too-early.patch @@ -0,0 +1,50 @@ +From effa24f689ce0948f68c754991a445a8d697d3a8 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Mon, 24 Jul 2023 06:26:53 -0700 +Subject: btrfs: don't stop integrity writeback too early + +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 +@@ -4024,11 +4024,12 @@ retry: + free_extent_buffer(eb); + + /* +- * 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); + } + pagevec_release(&pvec); + cond_resched(); diff --git a/queue-5.4/btrfs-don-t-wait-for-writeback-on-clean-pages-in-extent_write_cache_pages.patch b/queue-5.4/btrfs-don-t-wait-for-writeback-on-clean-pages-in-extent_write_cache_pages.patch new file mode 100644 index 00000000000..57dba92d785 --- /dev/null +++ b/queue-5.4/btrfs-don-t-wait-for-writeback-on-clean-pages-in-extent_write_cache_pages.patch @@ -0,0 +1,45 @@ +From 5c25699871112853f231e52d51c576d5c759a020 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Mon, 24 Jul 2023 06:26:54 -0700 +Subject: btrfs: don't wait for writeback on clean pages in extent_write_cache_pages + +From: Christoph Hellwig + +commit 5c25699871112853f231e52d51c576d5c759a020 upstream. + +__extent_writepage could have started on more pages than the one it was +called for. This happens regularly for zoned file systems, and in theory +could happen for compressed I/O if the worker thread was executed very +quickly. For such pages extent_write_cache_pages waits for writeback +to complete before moving on to the next page, which is highly inefficient +as it blocks the flusher thread. + +Port over the PageDirty check that was added to write_cache_pages in +commit 515f4a037fb ("mm: write_cache_pages optimise page cleaning") to +fix this. + +CC: stable@vger.kernel.org # 4.14+ +Reviewed-by: Josef Bacik +Signed-off-by: Christoph Hellwig +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent_io.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/btrfs/extent_io.c ++++ b/fs/btrfs/extent_io.c +@@ -4191,6 +4191,12 @@ retry: + continue; + } + ++ if (!folio_test_dirty(folio)) { ++ /* Someone wrote it for us. */ ++ folio_unlock(folio); ++ continue; ++ } ++ + if (wbc->sync_mode != WB_SYNC_NONE) { + if (PageWriteback(page)) { + ret = flush_write_bio(epd); diff --git a/queue-5.4/btrfs-set-cache_block_group_error-if-we-find-an-error.patch b/queue-5.4/btrfs-set-cache_block_group_error-if-we-find-an-error.patch new file mode 100644 index 00000000000..3e41998dd23 --- /dev/null +++ b/queue-5.4/btrfs-set-cache_block_group_error-if-we-find-an-error.patch @@ -0,0 +1,47 @@ +From 92fb94b69c6accf1e49fff699640fa0ce03dc910 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 2 Aug 2023 09:20:24 -0400 +Subject: btrfs: set cache_block_group_error if we find an error + +From: Josef Bacik + +commit 92fb94b69c6accf1e49fff699640fa0ce03dc910 upstream. + +We set cache_block_group_error if btrfs_cache_block_group() returns an +error, this is because we could end up not finding space to allocate and +mistakenly return -ENOSPC, and which could then abort the transaction +with the incorrect errno, and in the case of ENOSPC result in a +WARN_ON() that will trip up tests like generic/475. + +However there's the case where multiple threads can be racing, one +thread gets the proper error, and the other thread doesn't actually call +btrfs_cache_block_group(), it instead sees ->cached == +BTRFS_CACHE_ERROR. Again the result is the same, we fail to allocate +our space and return -ENOSPC. Instead we need to set +cache_block_group_error to -EIO in this case to make sure that if we do +not make our allocation we get the appropriate error returned back to +the caller. + +CC: stable@vger.kernel.org # 4.14+ +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent-tree.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -3989,8 +3989,11 @@ have_block_group: + ret = 0; + } + +- if (unlikely(block_group->cached == BTRFS_CACHE_ERROR)) ++ if (unlikely(block_group->cached == BTRFS_CACHE_ERROR)) { ++ if (!cache_block_group_error) ++ cache_block_group_error = -EIO; + goto loop; ++ } + + /* + * Ok we want to try and use the cluster allocator, so diff --git a/queue-5.4/series b/queue-5.4/series index 6b1261dfb6f..8a57a11cfc8 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -26,3 +26,6 @@ wifi-cfg80211-fix-sband-iftype-data-lookup-for-ap_vlan.patch dmaengine-mcf-edma-fix-a-potential-un-allocated-memory-access.patch net-mlx5-allow-0-for-total-host-vfs.patch ibmvnic-handle-dma-unmapping-of-login-buffs-in-release-functions.patch +btrfs-don-t-stop-integrity-writeback-too-early.patch +btrfs-don-t-wait-for-writeback-on-clean-pages-in-extent_write_cache_pages.patch +btrfs-set-cache_block_group_error-if-we-find-an-error.patch