May 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] platform/x86/intel-uncore-freq: Return error on write" 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 75e406b540c3eca67625d97bbefd4e3787eafbfe # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051328-colonist-quicken-0287@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 75e406b540c3 ("platform/x86/intel-uncore-freq: Return error on write frequency") dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part") 414eef27283a ("platform/x86/intel/uncore-freq: Display uncore current frequency") ae7b2ce57851 ("platform/x86/intel/uncore-freq: Use sysfs API to create attributes") ce2645c458b5 ("platform/x86/intel/uncore-freq: Move to uncore-frequency folder") 6dc69d3d0d18 ("Merge tag 'driver-core-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 75e406b540c3eca67625d97bbefd4e3787eafbfe Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Date: Tue, 18 Apr 2023 08:32:30 -0700 Subject: [PATCH] platform/x86/intel-uncore-freq: Return error on write frequency MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently when the uncore_write() returns error, it is silently ignored. Return error to user space when uncore_write() fails. Fixes: 49a474c7ba51 ("platform/x86: Add support for Uncore frequency control") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Reviewed-by: Zhang Rui <rui.zhang(a)intel.com> Tested-by: Wendy Wang <wendy.wang(a)intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Link: https://lore.kernel.org/r/20230418153230.679094-1-srinivas.pandruvada@linux… Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c index 1a300e14f350..064f186ae81b 100644 --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c @@ -44,14 +44,18 @@ static ssize_t store_min_max_freq_khz(struct uncore_data *data, int min_max) { unsigned int input; + int ret; if (kstrtouint(buf, 10, &input)) return -EINVAL; mutex_lock(&uncore_lock); - uncore_write(data, input, min_max); + ret = uncore_write(data, input, min_max); mutex_unlock(&uncore_lock); + if (ret) + return ret; + return count; }

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] platform/x86/intel-uncore-freq: Return error on write" 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 75e406b540c3eca67625d97bbefd4e3787eafbfe # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051324-calm-crummy-b754@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 75e406b540c3 ("platform/x86/intel-uncore-freq: Return error on write frequency") dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part") 414eef27283a ("platform/x86/intel/uncore-freq: Display uncore current frequency") ae7b2ce57851 ("platform/x86/intel/uncore-freq: Use sysfs API to create attributes") ce2645c458b5 ("platform/x86/intel/uncore-freq: Move to uncore-frequency folder") 6dc69d3d0d18 ("Merge tag 'driver-core-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 75e406b540c3eca67625d97bbefd4e3787eafbfe Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Date: Tue, 18 Apr 2023 08:32:30 -0700 Subject: [PATCH] platform/x86/intel-uncore-freq: Return error on write frequency MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently when the uncore_write() returns error, it is silently ignored. Return error to user space when uncore_write() fails. Fixes: 49a474c7ba51 ("platform/x86: Add support for Uncore frequency control") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Reviewed-by: Zhang Rui <rui.zhang(a)intel.com> Tested-by: Wendy Wang <wendy.wang(a)intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Link: https://lore.kernel.org/r/20230418153230.679094-1-srinivas.pandruvada@linux… Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c index 1a300e14f350..064f186ae81b 100644 --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c @@ -44,14 +44,18 @@ static ssize_t store_min_max_freq_khz(struct uncore_data *data, int min_max) { unsigned int input; + int ret; if (kstrtouint(buf, 10, &input)) return -EINVAL; mutex_lock(&uncore_lock); - uncore_write(data, input, min_max); + ret = uncore_write(data, input, min_max); mutex_unlock(&uncore_lock); + if (ret) + return ret; + return count; }

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix space cache inconsistency after error loading it" 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 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051309-surfacing-maroon-7092@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 0004ff15ea26 ("btrfs: fix space cache inconsistency after error loading it from disk") fa598b069640 ("btrfs: remove recalc_thresholds from free space ops") cd79909bc7cd ("btrfs: load free space cache into a temporary ctl") 6b7304af62d0 ("btrfs: rename member 'trimming' of block group to a more generic name") 2473d24f2b77 ("btrfs: fix a race between scrub and block group removal/allocation") 5d90c5c75711 ("btrfs: increase the metadata allowance for the free_space_cache") 7fe6d45e4009 ("btrfs: have multiple discard lists") 19b2a2c71979 ("btrfs: make max async discard size tunable") 4aa9ad520398 ("btrfs: limit max discard size for async discard") e93591bb6ecf ("btrfs: add kbps discard rate limit for async discard") a23093008412 ("btrfs: calculate discard delay based on number of extents") 5dc7c10b8747 ("btrfs: keep track of discardable_bytes for async discard") dfb79ddb130e ("btrfs: track discardable extents for async discard") e4faab844a55 ("btrfs: sysfs: add UUID/debug/discard directory") 93945cb43ead ("btrfs: sysfs: make UUID/debug have its own kobject") 71e8978eb456 ("btrfs: sysfs: add removal calls for debug/") 2bee7eb8bb81 ("btrfs: discard one region at a time in async discard") 6e80d4f8c422 ("btrfs: handle empty block_group removal for async discard") b0643e59cfa6 ("btrfs: add the beginning of async discard, discard workqueue") da080fe1bad4 ("btrfs: keep track of free space bitmap trim status cleanliness") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 4 May 2023 12:04:18 +0100 Subject: [PATCH] btrfs: fix space cache inconsistency after error loading it from disk When loading a free space cache from disk, at __load_free_space_cache(), if we fail to insert a bitmap entry, we still increment the number of total bitmaps in the btrfs_free_space_ctl structure, which is incorrect since we failed to add the bitmap entry. On error we then empty the cache by calling __btrfs_remove_free_space_cache(), which will result in getting the total bitmaps counter set to 1. A failure to load a free space cache is not critical, so if a failure happens we just rebuild the cache by scanning the extent tree, which happens at block-group.c:caching_thread(). Yet the failure will result in having the total bitmaps of the btrfs_free_space_ctl always bigger by 1 then the number of bitmap entries we have. So fix this by having the total bitmaps counter be incremented only if we successfully added the bitmap entry. Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache") Reviewed-by: Anand Jain <anand.jain(a)oracle.com> CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index d84cef89cdff..cf98a3c05480 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -870,15 +870,16 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode, } spin_lock(&ctl->tree_lock); ret = link_free_space(ctl, e); - ctl->total_bitmaps++; - recalculate_thresholds(ctl); - spin_unlock(&ctl->tree_lock); if (ret) { + spin_unlock(&ctl->tree_lock); btrfs_err(fs_info, "Duplicate entries in free space cache, dumping"); kmem_cache_free(btrfs_free_space_cachep, e); goto free_cache; } + ctl->total_bitmaps++; + recalculate_thresholds(ctl); + spin_unlock(&ctl->tree_lock); list_add_tail(&e->list, &bitmaps); }

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix space cache inconsistency after error loading it" 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 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051306-unwound-clapping-ac11@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 0004ff15ea26 ("btrfs: fix space cache inconsistency after error loading it from disk") fa598b069640 ("btrfs: remove recalc_thresholds from free space ops") cd79909bc7cd ("btrfs: load free space cache into a temporary ctl") 6b7304af62d0 ("btrfs: rename member 'trimming' of block group to a more generic name") 2473d24f2b77 ("btrfs: fix a race between scrub and block group removal/allocation") 5d90c5c75711 ("btrfs: increase the metadata allowance for the free_space_cache") 7fe6d45e4009 ("btrfs: have multiple discard lists") 19b2a2c71979 ("btrfs: make max async discard size tunable") 4aa9ad520398 ("btrfs: limit max discard size for async discard") e93591bb6ecf ("btrfs: add kbps discard rate limit for async discard") a23093008412 ("btrfs: calculate discard delay based on number of extents") 5dc7c10b8747 ("btrfs: keep track of discardable_bytes for async discard") dfb79ddb130e ("btrfs: track discardable extents for async discard") e4faab844a55 ("btrfs: sysfs: add UUID/debug/discard directory") 93945cb43ead ("btrfs: sysfs: make UUID/debug have its own kobject") 71e8978eb456 ("btrfs: sysfs: add removal calls for debug/") 2bee7eb8bb81 ("btrfs: discard one region at a time in async discard") 6e80d4f8c422 ("btrfs: handle empty block_group removal for async discard") b0643e59cfa6 ("btrfs: add the beginning of async discard, discard workqueue") da080fe1bad4 ("btrfs: keep track of free space bitmap trim status cleanliness") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 4 May 2023 12:04:18 +0100 Subject: [PATCH] btrfs: fix space cache inconsistency after error loading it from disk When loading a free space cache from disk, at __load_free_space_cache(), if we fail to insert a bitmap entry, we still increment the number of total bitmaps in the btrfs_free_space_ctl structure, which is incorrect since we failed to add the bitmap entry. On error we then empty the cache by calling __btrfs_remove_free_space_cache(), which will result in getting the total bitmaps counter set to 1. A failure to load a free space cache is not critical, so if a failure happens we just rebuild the cache by scanning the extent tree, which happens at block-group.c:caching_thread(). Yet the failure will result in having the total bitmaps of the btrfs_free_space_ctl always bigger by 1 then the number of bitmap entries we have. So fix this by having the total bitmaps counter be incremented only if we successfully added the bitmap entry. Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache") Reviewed-by: Anand Jain <anand.jain(a)oracle.com> CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index d84cef89cdff..cf98a3c05480 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -870,15 +870,16 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode, } spin_lock(&ctl->tree_lock); ret = link_free_space(ctl, e); - ctl->total_bitmaps++; - recalculate_thresholds(ctl); - spin_unlock(&ctl->tree_lock); if (ret) { + spin_unlock(&ctl->tree_lock); btrfs_err(fs_info, "Duplicate entries in free space cache, dumping"); kmem_cache_free(btrfs_free_space_cachep, e); goto free_cache; } + ctl->total_bitmaps++; + recalculate_thresholds(ctl); + spin_unlock(&ctl->tree_lock); list_add_tail(&e->list, &bitmaps); }

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix space cache inconsistency after error loading it" 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 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051302-outlet-silly-1404@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 0004ff15ea26 ("btrfs: fix space cache inconsistency after error loading it from disk") fa598b069640 ("btrfs: remove recalc_thresholds from free space ops") cd79909bc7cd ("btrfs: load free space cache into a temporary ctl") 6b7304af62d0 ("btrfs: rename member 'trimming' of block group to a more generic name") 2473d24f2b77 ("btrfs: fix a race between scrub and block group removal/allocation") 5d90c5c75711 ("btrfs: increase the metadata allowance for the free_space_cache") 7fe6d45e4009 ("btrfs: have multiple discard lists") 19b2a2c71979 ("btrfs: make max async discard size tunable") 4aa9ad520398 ("btrfs: limit max discard size for async discard") e93591bb6ecf ("btrfs: add kbps discard rate limit for async discard") a23093008412 ("btrfs: calculate discard delay based on number of extents") 5dc7c10b8747 ("btrfs: keep track of discardable_bytes for async discard") dfb79ddb130e ("btrfs: track discardable extents for async discard") e4faab844a55 ("btrfs: sysfs: add UUID/debug/discard directory") 93945cb43ead ("btrfs: sysfs: make UUID/debug have its own kobject") 71e8978eb456 ("btrfs: sysfs: add removal calls for debug/") 2bee7eb8bb81 ("btrfs: discard one region at a time in async discard") 6e80d4f8c422 ("btrfs: handle empty block_group removal for async discard") b0643e59cfa6 ("btrfs: add the beginning of async discard, discard workqueue") da080fe1bad4 ("btrfs: keep track of free space bitmap trim status cleanliness") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 4 May 2023 12:04:18 +0100 Subject: [PATCH] btrfs: fix space cache inconsistency after error loading it from disk When loading a free space cache from disk, at __load_free_space_cache(), if we fail to insert a bitmap entry, we still increment the number of total bitmaps in the btrfs_free_space_ctl structure, which is incorrect since we failed to add the bitmap entry. On error we then empty the cache by calling __btrfs_remove_free_space_cache(), which will result in getting the total bitmaps counter set to 1. A failure to load a free space cache is not critical, so if a failure happens we just rebuild the cache by scanning the extent tree, which happens at block-group.c:caching_thread(). Yet the failure will result in having the total bitmaps of the btrfs_free_space_ctl always bigger by 1 then the number of bitmap entries we have. So fix this by having the total bitmaps counter be incremented only if we successfully added the bitmap entry. Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache") Reviewed-by: Anand Jain <anand.jain(a)oracle.com> CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index d84cef89cdff..cf98a3c05480 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -870,15 +870,16 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode, } spin_lock(&ctl->tree_lock); ret = link_free_space(ctl, e); - ctl->total_bitmaps++; - recalculate_thresholds(ctl); - spin_unlock(&ctl->tree_lock); if (ret) { + spin_unlock(&ctl->tree_lock); btrfs_err(fs_info, "Duplicate entries in free space cache, dumping"); kmem_cache_free(btrfs_free_space_cachep, e); goto free_cache; } + ctl->total_bitmaps++; + recalculate_thresholds(ctl); + spin_unlock(&ctl->tree_lock); list_add_tail(&e->list, &bitmaps); }

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix space cache inconsistency after error loading it" 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 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051358-embattled-detest-37ff@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 0004ff15ea26 ("btrfs: fix space cache inconsistency after error loading it from disk") fa598b069640 ("btrfs: remove recalc_thresholds from free space ops") cd79909bc7cd ("btrfs: load free space cache into a temporary ctl") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 4 May 2023 12:04:18 +0100 Subject: [PATCH] btrfs: fix space cache inconsistency after error loading it from disk When loading a free space cache from disk, at __load_free_space_cache(), if we fail to insert a bitmap entry, we still increment the number of total bitmaps in the btrfs_free_space_ctl structure, which is incorrect since we failed to add the bitmap entry. On error we then empty the cache by calling __btrfs_remove_free_space_cache(), which will result in getting the total bitmaps counter set to 1. A failure to load a free space cache is not critical, so if a failure happens we just rebuild the cache by scanning the extent tree, which happens at block-group.c:caching_thread(). Yet the failure will result in having the total bitmaps of the btrfs_free_space_ctl always bigger by 1 then the number of bitmap entries we have. So fix this by having the total bitmaps counter be incremented only if we successfully added the bitmap entry. Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache") Reviewed-by: Anand Jain <anand.jain(a)oracle.com> CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index d84cef89cdff..cf98a3c05480 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -870,15 +870,16 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode, } spin_lock(&ctl->tree_lock); ret = link_free_space(ctl, e); - ctl->total_bitmaps++; - recalculate_thresholds(ctl); - spin_unlock(&ctl->tree_lock); if (ret) { + spin_unlock(&ctl->tree_lock); btrfs_err(fs_info, "Duplicate entries in free space cache, dumping"); kmem_cache_free(btrfs_free_space_cachep, e); goto free_cache; } + ctl->total_bitmaps++; + recalculate_thresholds(ctl); + spin_unlock(&ctl->tree_lock); list_add_tail(&e->list, &bitmaps); }

1 year, 8 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix encoded write i_size corruption with no-holes" 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 e7db9e5c6b9615b287d01f0231904fbc1fbde9c5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023051355-such-snowfall-6415@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: e7db9e5c6b96 ("btrfs: fix encoded write i_size corruption with no-holes") 76aea5379678 ("btrfs: make btrfs_inode_safe_disk_i_size_write take btrfs_inode") 2766ff61762c ("btrfs: update the number of bytes used by an inode atomically") 5893dfb98f25 ("btrfs: refactor btrfs_drop_extents() to make it easier to extend") ac5887c8e013 ("btrfs: locking: remove all the blocking helpers") a14b78ad06ab ("btrfs: introduce btrfs_inode_lock()/unlock()") b8d8e1fd570a ("btrfs: introduce btrfs_write_check()") c86537a42f86 ("btrfs: check FS error state bit early during write") 5e8b9ef30392 ("btrfs: move pos increment and pagecache extension to btrfs_buffered_write") 4e4cabece9f9 ("btrfs: split btrfs_direct_IO to read and write") 196d59ab9ccc ("btrfs: switch extent buffer tree lock to rw_semaphore") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e7db9e5c6b9615b287d01f0231904fbc1fbde9c5 Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Fri, 28 Apr 2023 14:02:11 -0700 Subject: [PATCH] btrfs: fix encoded write i_size corruption with no-holes We have observed a btrfs filesystem corruption on workloads using no-holes and encoded writes via send stream v2. The symptom is that a file appears to be truncated to the end of its last aligned extent, even though the final unaligned extent and even the file extent and otherwise correctly updated inode item have been written. So if we were writing out a 1MiB+X file via 8 128K extents and one extent of length X, i_size would be set to 1MiB, but the ninth extent, nbyte, etc. would all appear correct otherwise. The source of the race is a narrow (one line of code) window in which a no-holes fs has read in an updated i_size, but has not yet set a shared disk_i_size variable to write. Therefore, if two ordered extents run in parallel (par for the course for receive workloads), the following sequence can play out: (following "threads" a bit loosely, since there are callbacks involved for endio but extra threads aren't needed to cause the issue) ENC-WR1 (second to last) ENC-WR2 (last) ------- ------- btrfs_do_encoded_write set i_size = 1M submit bio B1 ending at 1M endio B1 btrfs_inode_safe_disk_i_size_write local i_size = 1M falls off a cliff for some reason btrfs_do_encoded_write set i_size = 1M+X submit bio B2 ending at 1M+X endio B2 btrfs_inode_safe_disk_i_size_write local i_size = 1M+X disk_i_size = 1M+X disk_i_size = 1M btrfs_delayed_update_inode btrfs_delayed_update_inode And the delayed inode ends up filled with nbytes=1M+X and isize=1M, and writes respect i_size and present a corrupted file missing its last extents. Fix this by holding the inode lock in the no-holes case so that a thread can't sneak in a write to disk_i_size that gets overwritten with an out of date i_size. Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree") CC: stable(a)vger.kernel.org # 5.10+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c index 018c711a0bc8..cd4cce9ba443 100644 --- a/fs/btrfs/file-item.c +++ b/fs/btrfs/file-item.c @@ -52,13 +52,13 @@ void btrfs_inode_safe_disk_i_size_write(struct btrfs_inode *inode, u64 new_i_siz u64 start, end, i_size; int ret; + spin_lock(&inode->lock); i_size = new_i_size ?: i_size_read(&inode->vfs_inode); if (btrfs_fs_incompat(fs_info, NO_HOLES)) { inode->disk_i_size = i_size; - return; + goto out_unlock; } - spin_lock(&inode->lock); ret = find_contiguous_extent_bit(&inode->file_extent_tree, 0, &start, &end, EXTENT_DIRTY); if (!ret && start == 0) @@ -66,6 +66,7 @@ void btrfs_inode_safe_disk_i_size_write(struct btrfs_inode *inode, u64 new_i_siz else i_size = 0; inode->disk_i_size = i_size; +out_unlock: spin_unlock(&inode->lock); }

1 year, 8 months

1
0
0 0

[PATCH netfilter -stable,4.14 0/6] stable fixes for 4.14

by Pablo Neira Ayuso

Hi Greg, Sasha, This is a backport of c1592a89942e ("netfilter: nf_tables: deactivate anonymous set from preparation phase") which fixes CVE-2023-32233. This patch requires dependency fixes which are not currently in the 4.14 branch. The following list shows the backported patches, I am using original commit IDs for reference: 1) cd5125d8f518 ("netfilter: nf_tables: split set destruction in deactivate and destroy phase") 2) f6ac85858976 ("netfilter: nf_tables: unbind set in rule from commit path") 3) 7f4dae2d7f03 ("netfilter: nft_hash: fix nft_hash_deactivate") 4) 6a0a8d10a366 ("netfilter: nf_tables: use-after-free in failing rule with bound set") 5) 273fe3f1006e ("netfilter: nf_tables: bogus EBUSY when deleting set after flush") 6) c1592a89942e ("netfilter: nf_tables: deactivate anonymous set from preparation phase") Please apply to 4.14-stable. Thanks. Florian Westphal (1): netfilter: nf_tables: split set destruction in deactivate and destroy phase Pablo Neira Ayuso (5): netfilter: nf_tables: unbind set in rule from commit path netfilter: nft_hash: fix nft_hash_deactivate netfilter: nf_tables: use-after-free in failing rule with bound set netfilter: nf_tables: bogus EBUSY when deleting set after flush netfilter: nf_tables: deactivate anonymous set from preparation phase include/net/netfilter/nf_tables.h | 30 ++++++- net/netfilter/nf_tables_api.c | 139 +++++++++++++++++++++--------- net/netfilter/nft_dynset.c | 22 ++++- net/netfilter/nft_immediate.c | 6 +- net/netfilter/nft_lookup.c | 21 ++++- net/netfilter/nft_objref.c | 21 ++++- net/netfilter/nft_set_hash.c | 2 +- 7 files changed, 194 insertions(+), 47 deletions(-) -- 2.30.2

1 year, 8 months

4
9
0 0

[PATCH] ext4: Avoid a potential slab-out-of-bounds in ext4_group_desc_csum

by Tudor Ambarus

When modifying the block device while it is mounted by the filesystem, syzbot reported the following: BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58 Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586 CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc96618275234 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 crc16+0x206/0x280 lib/crc16.c:58 ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187 ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210 ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline] ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173 ext4_remove_blocks fs/ext4/extents.c:2527 [inline] ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline] ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958 ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416 ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342 ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622 notify_change+0xe50/0x1100 fs/attr.c:482 do_truncate+0x200/0x2f0 fs/open.c:65 handle_truncate fs/namei.c:3216 [inline] do_open fs/namei.c:3561 [inline] path_openat+0x272b/0x2dd0 fs/namei.c:3714 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f72f8a8c0c9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280 RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000 Replace le16_to_cpu(sbi->s_es->s_desc_size) with sbi->s_desc_size It reduces ext4's compiled text size, and makes the code more efficient (we remove an extra indirect reference and a potential byte swap on big endian systems), and there is no downside. It also avoids the potential KASAN / syzkaller failure, as a bonus. Reported-by: syzbot+fc51227e7100c9294894(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30… Link: https://lore.kernel.org/all/000000000000ece18705f3b20934@google.com/ Fixes: 717d50e4971b ("Ext4: Uninitialized Block Groups") Cc: stable(a)vger.kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> --- fs/ext4/super.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index d39f386e9baf..e3d0d3c04785 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3238,11 +3238,9 @@ static __le16 ext4_group_desc_csum(struct super_block *sb, __u32 block_group, crc = crc16(crc, (__u8 *)gdp, offset); offset += sizeof(gdp->bg_checksum); /* skip checksum */ /* for checksum of struct ext4_group_desc do the rest...*/ - if (ext4_has_feature_64bit(sb) && - offset < le16_to_cpu(sbi->s_es->s_desc_size)) + if (ext4_has_feature_64bit(sb) && offset < sbi->s_desc_size) crc = crc16(crc, (__u8 *)gdp + offset, - le16_to_cpu(sbi->s_es->s_desc_size) - - offset); + sbi->s_desc_size - offset); out: return cpu_to_le16(crc); -- 2.40.1.495.gc816e09b53d-goog

1 year, 8 months

2
1
0 0

[PATCH] ext4: Avoid deadlock in fs reclaim with page writeback

by Jan Kara

Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock. Reported-by: syzbot+6898da502aef574c5f8a(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/0000000000004c66b405fa108e27@google.com Fixes: c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages") CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/ext4.h | 24 ++++++++++++++++++++++++ fs/ext4/inode.c | 18 ++++++++++-------- fs/ext4/migrate.c | 11 ++++++----- 3 files changed, 40 insertions(+), 13 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 18cb2680dc39..92df861227dd 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1684,6 +1684,30 @@ static inline struct ext4_inode_info *EXT4_I(struct inode *inode) return container_of(inode, struct ext4_inode_info, vfs_inode); } +static inline int ext4_writepages_down_read(struct super_block *sb) +{ + percpu_down_read(&EXT4_SB(sb)->s_writepages_rwsem); + return memalloc_nofs_save(); +} + +static inline void ext4_writepages_up_read(struct super_block *sb, int ctx) +{ + memalloc_nofs_restore(ctx); + percpu_up_read(&EXT4_SB(sb)->s_writepages_rwsem); +} + +static inline int ext4_writepages_down_write(struct super_block *sb) +{ + percpu_down_write(&EXT4_SB(sb)->s_writepages_rwsem); + return memalloc_nofs_save(); +} + +static inline void ext4_writepages_up_write(struct super_block *sb, int ctx) +{ + memalloc_nofs_restore(ctx); + percpu_up_write(&EXT4_SB(sb)->s_writepages_rwsem); +} + static inline int ext4_valid_inum(struct super_block *sb, unsigned long ino) { return ino == EXT4_ROOT_INO || diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index ffbbd9626bd8..b6dc795b61ad 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -2783,11 +2783,12 @@ static int ext4_writepages(struct address_space *mapping, .can_map = 1, }; int ret; + int alloc_ctx; if (unlikely(ext4_forced_shutdown(EXT4_SB(sb)))) return -EIO; - percpu_down_read(&EXT4_SB(sb)->s_writepages_rwsem); + alloc_ctx = ext4_writepages_down_read(sb); ret = ext4_do_writepages(&mpd); /* * For data=journal writeback we could have come across pages marked @@ -2796,7 +2797,7 @@ static int ext4_writepages(struct address_space *mapping, */ if (!ret && mpd.journalled_more_data) ret = ext4_do_writepages(&mpd); - percpu_up_read(&EXT4_SB(sb)->s_writepages_rwsem); + ext4_writepages_up_read(sb, alloc_ctx); return ret; } @@ -2824,17 +2825,18 @@ static int ext4_dax_writepages(struct address_space *mapping, long nr_to_write = wbc->nr_to_write; struct inode *inode = mapping->host; struct ext4_sb_info *sbi = EXT4_SB(mapping->host->i_sb); + int alloc_ctx; if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb)))) return -EIO; - percpu_down_read(&sbi->s_writepages_rwsem); + alloc_ctx = ext4_writepages_down_read(inode->i_sb); trace_ext4_writepages(inode, wbc); ret = dax_writeback_mapping_range(mapping, sbi->s_daxdev, wbc); trace_ext4_writepages_result(inode, wbc, ret, nr_to_write - wbc->nr_to_write); - percpu_up_read(&sbi->s_writepages_rwsem); + ext4_writepages_up_read(inode->i_sb, alloc_ctx); return ret; } @@ -5925,7 +5927,7 @@ int ext4_change_inode_journal_flag(struct inode *inode, int val) journal_t *journal; handle_t *handle; int err; - struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); + int alloc_ctx; /* * We have to be very careful here: changing a data block's @@ -5963,7 +5965,7 @@ int ext4_change_inode_journal_flag(struct inode *inode, int val) } } - percpu_down_write(&sbi->s_writepages_rwsem); + alloc_ctx = ext4_writepages_down_write(inode->i_sb); jbd2_journal_lock_updates(journal); /* @@ -5980,7 +5982,7 @@ int ext4_change_inode_journal_flag(struct inode *inode, int val) err = jbd2_journal_flush(journal, 0); if (err < 0) { jbd2_journal_unlock_updates(journal); - percpu_up_write(&sbi->s_writepages_rwsem); + ext4_writepages_up_write(inode->i_sb, alloc_ctx); return err; } ext4_clear_inode_flag(inode, EXT4_INODE_JOURNAL_DATA); @@ -5988,7 +5990,7 @@ int ext4_change_inode_journal_flag(struct inode *inode, int val) ext4_set_aops(inode); jbd2_journal_unlock_updates(journal); - percpu_up_write(&sbi->s_writepages_rwsem); + ext4_writepages_up_write(inode->i_sb, alloc_ctx); if (val) filemap_invalidate_unlock(inode->i_mapping); diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c index a19a9661646e..d98ac2af8199 100644 --- a/fs/ext4/migrate.c +++ b/fs/ext4/migrate.c @@ -408,7 +408,6 @@ static int free_ext_block(handle_t *handle, struct inode *inode) int ext4_ext_migrate(struct inode *inode) { - struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); handle_t *handle; int retval = 0, i; __le32 *i_data; @@ -418,6 +417,7 @@ int ext4_ext_migrate(struct inode *inode) unsigned long max_entries; __u32 goal, tmp_csum_seed; uid_t owner[2]; + int alloc_ctx; /* * If the filesystem does not support extents, or the inode @@ -434,7 +434,7 @@ int ext4_ext_migrate(struct inode *inode) */ return retval; - percpu_down_write(&sbi->s_writepages_rwsem); + alloc_ctx = ext4_writepages_down_write(inode->i_sb); /* * Worst case we can touch the allocation bitmaps and a block @@ -586,7 +586,7 @@ int ext4_ext_migrate(struct inode *inode) unlock_new_inode(tmp_inode); iput(tmp_inode); out_unlock: - percpu_up_write(&sbi->s_writepages_rwsem); + ext4_writepages_up_write(inode->i_sb, alloc_ctx); return retval; } @@ -605,6 +605,7 @@ int ext4_ind_migrate(struct inode *inode) ext4_fsblk_t blk; handle_t *handle; int ret, ret2 = 0; + int alloc_ctx; if (!ext4_has_feature_extents(inode->i_sb) || (!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) @@ -621,7 +622,7 @@ int ext4_ind_migrate(struct inode *inode) if (test_opt(inode->i_sb, DELALLOC)) ext4_alloc_da_blocks(inode); - percpu_down_write(&sbi->s_writepages_rwsem); + alloc_ctx = ext4_writepages_down_write(inode->i_sb); handle = ext4_journal_start(inode, EXT4_HT_MIGRATE, 1); if (IS_ERR(handle)) { @@ -665,6 +666,6 @@ int ext4_ind_migrate(struct inode *inode) ext4_journal_stop(handle); up_write(&EXT4_I(inode)->i_data_sem); out_unlock: - percpu_up_write(&sbi->s_writepages_rwsem); + ext4_writepages_up_write(inode->i_sb, alloc_ctx); return ret; } -- 2.35.3

1 year, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2023