August 2023 - Linux-stable-mirror

[PATCH -stable,5.10 0/1] netfilter stable fix for 5.10

by Pablo Neira Ayuso

Hi Greg, Sasha, This is a backport of: 1689f25924ad ("netfilter: nf_tables: report use refcount overflow") for -stable 5.10. Please, apply. Pablo Neira Ayuso (1): netfilter: nf_tables: report use refcount overflow include/net/netfilter/nf_tables.h | 31 +++++- net/netfilter/nf_tables_api.c | 171 ++++++++++++++++++------------ net/netfilter/nft_flow_offload.c | 6 +- net/netfilter/nft_immediate.c | 8 +- net/netfilter/nft_objref.c | 8 +- 5 files changed, 145 insertions(+), 79 deletions(-) -- 2.30.2

1 year, 8 months

1
1
0 0

[PATCH -stable,5.15 0/1] netfilter stable fix for 5.15

by Pablo Neira Ayuso

Hi Greg, Sasha, This is a backport of: 1689f25924ad ("netfilter: nf_tables: report use refcount overflow") for -stable 5.15. Please, apply. Thanks. Pablo Neira Ayuso (1): netfilter: nf_tables: report use refcount overflow include/net/netfilter/nf_tables.h | 31 +++++- net/netfilter/nf_tables_api.c | 164 ++++++++++++++++++------------ net/netfilter/nft_flow_offload.c | 6 +- net/netfilter/nft_immediate.c | 8 +- net/netfilter/nft_objref.c | 8 +- 5 files changed, 141 insertions(+), 76 deletions(-) -- 2.30.2

1 year, 8 months

1
1
0 0

[PATCH -stable,6.1 0/1] netfilter stable fix for 6.1

by Pablo Neira Ayuso

Hi Greg, Sasha, This is a backport of: 1689f25924ad ("netfilter: nf_tables: report use refcount overflow") for -stable 6.1. Please, apply. Thanks. Pablo Neira Ayuso (1): netfilter: nf_tables: report use refcount overflow include/net/netfilter/nf_tables.h | 31 +++++- net/netfilter/nf_tables_api.c | 163 ++++++++++++++++++------------ net/netfilter/nft_flow_offload.c | 6 +- net/netfilter/nft_immediate.c | 8 +- net/netfilter/nft_objref.c | 8 +- 5 files changed, 141 insertions(+), 75 deletions(-) -- 2.30.2

1 year, 8 months

1
1
0 0

FAILED: patch "[PATCH] io_uring: correct check for O_TMPFILE" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 72dbde0f2afbe4af8e8595a89c650ae6b9d9c36f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081258-sturdy-retying-2572@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 72dbde0f2afb ("io_uring: correct check for O_TMPFILE") 0ffae640ad83 ("io_uring: always go async for unsupported open flags") cd40cae29ef8 ("io_uring: split out open/close operations") 453b329be5ea ("io_uring: separate out file table handling code") f4c163dd7d4b ("io_uring: split out fadvise/madvise operations") 0d5847274037 ("io_uring: split out fs related sync/fallocate functions") 531113bbd5bf ("io_uring: split out splice related operations") 11aeb71406dd ("io_uring: split out filesystem related operations") e28683bdfc2f ("io_uring: move nop into its own file") 5e2a18d93fec ("io_uring: move xattr related opcodes to its own file") 97b388d70b53 ("io_uring: handle completions in the core") de23077eda61 ("io_uring: set completion results upfront") e27f928ee1cb ("io_uring: add io_uring_types.h") 4d4c9cff4f70 ("io_uring: define a request type cleanup handler") 890968dc0336 ("io_uring: unify struct io_symlink and io_hardlink") 9a3a11f977f9 ("io_uring: convert iouring_cmd to io_cmd_type") ceb452e1b4ba ("io_uring: convert xattr to use io_cmd_type") ea5af87d29cf ("io_uring: convert rsrc_update to io_cmd_type") c1ee55950155 ("io_uring: convert msg and nop to io_cmd_type") 2511d3030c5e ("io_uring: convert splice to use io_cmd_type") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 72dbde0f2afbe4af8e8595a89c650ae6b9d9c36f Mon Sep 17 00:00:00 2001 From: Aleksa Sarai <cyphar(a)cyphar.com> Date: Mon, 7 Aug 2023 12:24:15 +1000 Subject: [PATCH] io_uring: correct check for O_TMPFILE O_TMPFILE is actually __O_TMPFILE|O_DIRECTORY. This means that the old check for whether RESOLVE_CACHED can be used would incorrectly think that O_DIRECTORY could not be used with RESOLVE_CACHED. Cc: stable(a)vger.kernel.org # v5.12+ Fixes: 3a81fd02045c ("io_uring: enable LOOKUP_CACHED path resolution for filename lookups") Signed-off-by: Aleksa Sarai <cyphar(a)cyphar.com> Link: https://lore.kernel.org/r/20230807-resolve_cached-o_tmpfile-v3-1-e49323e1ef… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/openclose.c b/io_uring/openclose.c index 10ca57f5bd24..e3fae26e025d 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -35,9 +35,11 @@ static bool io_openat_force_async(struct io_open *open) { /* * Don't bother trying for O_TRUNC, O_CREAT, or O_TMPFILE open, - * it'll always -EAGAIN + * it'll always -EAGAIN. Note that we test for __O_TMPFILE because + * O_TMPFILE includes O_DIRECTORY, which isn't a flag we need to force + * async for. */ - return open->how.flags & (O_TRUNC | O_CREAT | O_TMPFILE); + return open->how.flags & (O_TRUNC | O_CREAT | __O_TMPFILE); } static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)

1 year, 8 months

3
4
0 0

FAILED: patch "[PATCH] btrfs: set cache_block_group_error if we find an error" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 92fb94b69c6accf1e49fff699640fa0ce03dc910 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081201-unmoving-diameter-8fa3@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 92fb94b69c6accf1e49fff699640fa0ce03dc910 Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Wed, 2 Aug 2023 09:20:24 -0400 Subject: [PATCH] btrfs: set cache_block_group_error if we find an error 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(a)vger.kernel.org # 4.14+ Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 911908ea5f6f..f396a9afa403 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4310,8 +4310,11 @@ static noinline int find_free_extent(struct btrfs_root *root, 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; + } if (!find_free_extent_check_size_class(ffe_ctl, block_group)) goto loop;

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: set cache_block_group_error if we find an error" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 92fb94b69c6accf1e49fff699640fa0ce03dc910 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081259-hammock-private-d316@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 92fb94b69c6accf1e49fff699640fa0ce03dc910 Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Wed, 2 Aug 2023 09:20:24 -0400 Subject: [PATCH] btrfs: set cache_block_group_error if we find an error 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(a)vger.kernel.org # 4.14+ Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 911908ea5f6f..f396a9afa403 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4310,8 +4310,11 @@ static noinline int find_free_extent(struct btrfs_root *root, 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; + } if (!find_free_extent_check_size_class(ffe_ctl, block_group)) goto loop;

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: don't wait for writeback on clean pages in" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 5c25699871112853f231e52d51c576d5c759a020 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081248-stuffed-rematch-3c0b@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5c25699871112853f231e52d51c576d5c759a020 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Mon, 24 Jul 2023 06:26:54 -0700 Subject: [PATCH] btrfs: don't wait for writeback on clean pages in extent_write_cache_pages __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(a)vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index c36eb4956f81..ca765d62324f 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2145,6 +2145,12 @@ static int extent_write_cache_pages(struct address_space *mapping, continue; } + if (!folio_test_dirty(folio)) { + /* Someone wrote it for us. */ + folio_unlock(folio); + continue; + } + if (wbc->sync_mode != WB_SYNC_NONE) { if (folio_test_writeback(folio)) submit_write_bio(bio_ctrl, 0);

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: don't wait for writeback on clean pages in" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 5c25699871112853f231e52d51c576d5c759a020 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081247-fiddling-guise-6829@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5c25699871112853f231e52d51c576d5c759a020 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Mon, 24 Jul 2023 06:26:54 -0700 Subject: [PATCH] btrfs: don't wait for writeback on clean pages in extent_write_cache_pages __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(a)vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index c36eb4956f81..ca765d62324f 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2145,6 +2145,12 @@ static int extent_write_cache_pages(struct address_space *mapping, continue; } + if (!folio_test_dirty(folio)) { + /* Someone wrote it for us. */ + folio_unlock(folio); + continue; + } + if (wbc->sync_mode != WB_SYNC_NONE) { if (folio_test_writeback(folio)) submit_write_bio(bio_ctrl, 0);

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: don't wait for writeback on clean pages in" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 5c25699871112853f231e52d51c576d5c759a020 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081246-grandson-evasive-6acf@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5c25699871112853f231e52d51c576d5c759a020 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Mon, 24 Jul 2023 06:26:54 -0700 Subject: [PATCH] btrfs: don't wait for writeback on clean pages in extent_write_cache_pages __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(a)vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index c36eb4956f81..ca765d62324f 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2145,6 +2145,12 @@ static int extent_write_cache_pages(struct address_space *mapping, continue; } + if (!folio_test_dirty(folio)) { + /* Someone wrote it for us. */ + folio_unlock(folio); + continue; + } + if (wbc->sync_mode != WB_SYNC_NONE) { if (folio_test_writeback(folio)) submit_write_bio(bio_ctrl, 0);

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: don't wait for writeback on clean pages in" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 5c25699871112853f231e52d51c576d5c759a020 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023081245-skyline-foster-b420@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5c25699871112853f231e52d51c576d5c759a020 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Mon, 24 Jul 2023 06:26:54 -0700 Subject: [PATCH] btrfs: don't wait for writeback on clean pages in extent_write_cache_pages __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(a)vger.kernel.org # 4.14+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index c36eb4956f81..ca765d62324f 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2145,6 +2145,12 @@ static int extent_write_cache_pages(struct address_space *mapping, continue; } + if (!folio_test_dirty(folio)) { + /* Someone wrote it for us. */ + folio_unlock(folio); + continue; + } + if (wbc->sync_mode != WB_SYNC_NONE) { if (folio_test_writeback(folio)) submit_write_bio(bio_ctrl, 0);

1 year, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2023