October 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] drm/vc4: Stop the active perfmon before being destroyed" 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 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101424-skinning-tightness-ecf1@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 0b2ad4f6f2be ("drm/vc4: Stop the active perfmon before being destroyed") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal(a)igalia.com> Date: Fri, 4 Oct 2024 09:36:00 -0300 Subject: [PATCH] drm/vc4: Stop the active perfmon before being destroyed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable(a)vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Juan A. Suarez Romero <jasuarez(a)igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Juan A. Suarez <jasuarez(a)igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcana… diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c b/drivers/gpu/drm/vc4/vc4_perfmon.c index c4ac2c946238..c00a5cc2316d 100644 --- a/drivers/gpu/drm/vc4/vc4_perfmon.c +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c @@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_file *vc4file) static int vc4_perfmon_idr_del(int id, void *elem, void *data) { struct vc4_perfmon *perfmon = elem; + struct vc4_dev *vc4 = (struct vc4_dev *)data; + + /* If the active perfmon is being destroyed, stop it first */ + if (perfmon == vc4->active_perfmon) + vc4_perfmon_stop(vc4, perfmon, false); vc4_perfmon_put(perfmon); @@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file) return; mutex_lock(&vc4file->perfmon.lock); - idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); + idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); idr_destroy(&vc4file->perfmon.idr); mutex_unlock(&vc4file->perfmon.lock); mutex_destroy(&vc4file->perfmon.lock);

1 week

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Stop the active perfmon before being destroyed" 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 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101412-stipulate-plentiful-20b6@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 0b2ad4f6f2be ("drm/vc4: Stop the active perfmon before being destroyed") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal(a)igalia.com> Date: Fri, 4 Oct 2024 09:36:00 -0300 Subject: [PATCH] drm/vc4: Stop the active perfmon before being destroyed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable(a)vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Juan A. Suarez Romero <jasuarez(a)igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Juan A. Suarez <jasuarez(a)igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcana… diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c b/drivers/gpu/drm/vc4/vc4_perfmon.c index c4ac2c946238..c00a5cc2316d 100644 --- a/drivers/gpu/drm/vc4/vc4_perfmon.c +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c @@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_file *vc4file) static int vc4_perfmon_idr_del(int id, void *elem, void *data) { struct vc4_perfmon *perfmon = elem; + struct vc4_dev *vc4 = (struct vc4_dev *)data; + + /* If the active perfmon is being destroyed, stop it first */ + if (perfmon == vc4->active_perfmon) + vc4_perfmon_stop(vc4, perfmon, false); vc4_perfmon_put(perfmon); @@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file) return; mutex_lock(&vc4file->perfmon.lock); - idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); + idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); idr_destroy(&vc4file->perfmon.idr); mutex_unlock(&vc4file->perfmon.lock); mutex_destroy(&vc4file->perfmon.lock);

1 week

1
0
0 0

FAILED: patch "[PATCH] net: dsa: lan9303: ensure chip reset and wait for READY" 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 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101451-twisting-shorts-fd38@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 5c14e51d2d7d ("net: dsa: lan9303: ensure chip reset and wait for READY status") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff Mon Sep 17 00:00:00 2001 From: Anatolij Gustschin <agust(a)denx.de> Date: Fri, 4 Oct 2024 13:36:54 +0200 Subject: [PATCH] net: dsa: lan9303: ensure chip reset and wait for READY status Accessing device registers seems to be not reliable, the chip revision is sometimes detected wrongly (0 instead of expected 1). Ensure that the chip reset is performed via reset GPIO and then wait for 'Device Ready' status in HW_CFG register before doing any register initializations. Cc: stable(a)vger.kernel.org Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303") Signed-off-by: Anatolij Gustschin <agust(a)denx.de> [alex: reworked using read_poll_timeout()] Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> Reviewed-by: Vladimir Oltean <olteanv(a)gmail.com> Link: https://patch.msgid.link/20241004113655.3436296-1-alexander.sverdlin@siemen… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c index 268949939636..d246f95d57ec 100644 --- a/drivers/net/dsa/lan9303-core.c +++ b/drivers/net/dsa/lan9303-core.c @@ -6,6 +6,7 @@ #include <linux/module.h> #include <linux/gpio/consumer.h> #include <linux/regmap.h> +#include <linux/iopoll.h> #include <linux/mutex.h> #include <linux/mii.h> #include <linux/of.h> @@ -839,6 +840,8 @@ static void lan9303_handle_reset(struct lan9303 *chip) if (!chip->reset_gpio) return; + gpiod_set_value_cansleep(chip->reset_gpio, 1); + if (chip->reset_duration != 0) msleep(chip->reset_duration); @@ -864,8 +867,34 @@ static int lan9303_disable_processing(struct lan9303 *chip) static int lan9303_check_device(struct lan9303 *chip) { int ret; + int err; u32 reg; + /* In I2C-managed configurations this polling loop will clash with + * switch's reading of EEPROM right after reset and this behaviour is + * not configurable. While lan9303_read() already has quite long retry + * timeout, seems not all cases are being detected as arbitration error. + * + * According to datasheet, EEPROM loader has 30ms timeout (in case of + * missing EEPROM). + * + * Loading of the largest supported EEPROM is expected to take at least + * 5.9s. + */ + err = read_poll_timeout(lan9303_read, ret, + !ret && reg & LAN9303_HW_CFG_READY, + 20000, 6000000, false, + chip->regmap, LAN9303_HW_CFG, &reg); + if (ret) { + dev_err(chip->dev, "failed to read HW_CFG reg: %pe\n", + ERR_PTR(ret)); + return ret; + } + if (err) { + dev_err(chip->dev, "HW_CFG not ready: 0x%08x\n", reg); + return err; + } + ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg); if (ret) { dev_err(chip->dev, "failed to read chip revision register: %d\n",

1 week

1
0
0 0

FAILED: patch "[PATCH] drm/vc4: Stop the active perfmon before being destroyed" 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 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101431-able-caress-7fe5@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 0b2ad4f6f2be ("drm/vc4: Stop the active perfmon before being destroyed") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal(a)igalia.com> Date: Fri, 4 Oct 2024 09:36:00 -0300 Subject: [PATCH] drm/vc4: Stop the active perfmon before being destroyed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable(a)vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon(a)kernel.org> Cc: Juan A. Suarez Romero <jasuarez(a)igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Juan A. Suarez <jasuarez(a)igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcana… diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c b/drivers/gpu/drm/vc4/vc4_perfmon.c index c4ac2c946238..c00a5cc2316d 100644 --- a/drivers/gpu/drm/vc4/vc4_perfmon.c +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c @@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_file *vc4file) static int vc4_perfmon_idr_del(int id, void *elem, void *data) { struct vc4_perfmon *perfmon = elem; + struct vc4_dev *vc4 = (struct vc4_dev *)data; + + /* If the active perfmon is being destroyed, stop it first */ + if (perfmon == vc4->active_perfmon) + vc4_perfmon_stop(vc4, perfmon, false); vc4_perfmon_put(perfmon); @@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file) return; mutex_lock(&vc4file->perfmon.lock); - idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); + idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); idr_destroy(&vc4file->perfmon.idr); mutex_unlock(&vc4file->perfmon.lock); mutex_destroy(&vc4file->perfmon.lock);

1 week

1
0
0 0

FAILED: patch "[PATCH] net: dsa: lan9303: ensure chip reset and wait for READY" 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 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101400-rectal-cattle-3833@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 5c14e51d2d7d ("net: dsa: lan9303: ensure chip reset and wait for READY status") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff Mon Sep 17 00:00:00 2001 From: Anatolij Gustschin <agust(a)denx.de> Date: Fri, 4 Oct 2024 13:36:54 +0200 Subject: [PATCH] net: dsa: lan9303: ensure chip reset and wait for READY status Accessing device registers seems to be not reliable, the chip revision is sometimes detected wrongly (0 instead of expected 1). Ensure that the chip reset is performed via reset GPIO and then wait for 'Device Ready' status in HW_CFG register before doing any register initializations. Cc: stable(a)vger.kernel.org Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303") Signed-off-by: Anatolij Gustschin <agust(a)denx.de> [alex: reworked using read_poll_timeout()] Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> Reviewed-by: Vladimir Oltean <olteanv(a)gmail.com> Link: https://patch.msgid.link/20241004113655.3436296-1-alexander.sverdlin@siemen… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c index 268949939636..d246f95d57ec 100644 --- a/drivers/net/dsa/lan9303-core.c +++ b/drivers/net/dsa/lan9303-core.c @@ -6,6 +6,7 @@ #include <linux/module.h> #include <linux/gpio/consumer.h> #include <linux/regmap.h> +#include <linux/iopoll.h> #include <linux/mutex.h> #include <linux/mii.h> #include <linux/of.h> @@ -839,6 +840,8 @@ static void lan9303_handle_reset(struct lan9303 *chip) if (!chip->reset_gpio) return; + gpiod_set_value_cansleep(chip->reset_gpio, 1); + if (chip->reset_duration != 0) msleep(chip->reset_duration); @@ -864,8 +867,34 @@ static int lan9303_disable_processing(struct lan9303 *chip) static int lan9303_check_device(struct lan9303 *chip) { int ret; + int err; u32 reg; + /* In I2C-managed configurations this polling loop will clash with + * switch's reading of EEPROM right after reset and this behaviour is + * not configurable. While lan9303_read() already has quite long retry + * timeout, seems not all cases are being detected as arbitration error. + * + * According to datasheet, EEPROM loader has 30ms timeout (in case of + * missing EEPROM). + * + * Loading of the largest supported EEPROM is expected to take at least + * 5.9s. + */ + err = read_poll_timeout(lan9303_read, ret, + !ret && reg & LAN9303_HW_CFG_READY, + 20000, 6000000, false, + chip->regmap, LAN9303_HW_CFG, &reg); + if (ret) { + dev_err(chip->dev, "failed to read HW_CFG reg: %pe\n", + ERR_PTR(ret)); + return ret; + } + if (err) { + dev_err(chip->dev, "HW_CFG not ready: 0x%08x\n", reg); + return err; + } + ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg); if (ret) { dev_err(chip->dev, "failed to read chip revision register: %d\n",

1 week

1
0
0 0

FAILED: patch "[PATCH] btrfs: add cancellation points to trim loops" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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-6.1.y git checkout FETCH_HEAD git cherry-pick -x 69313850dce33ce8c24b38576a279421f4c60996 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101412-backfire-pacific-1f0b@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 69313850dce3 ("btrfs: add cancellation points to trim loops") a99fcb015897 ("btrfs: split remaining space to discard in chunks") 602035d7fecf ("btrfs: add forward declarations and headers, part 2") 22b46bdc5f11 ("btrfs: add forward declarations and headers, part 1") 2b712e3bb2c4 ("btrfs: remove unused included headers") f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type") 1a9fb16c6052 ("btrfs: avoid useless rbtree iterations when attempting to merge extent map") ad21f15b0f79 ("btrfs: switch to the new mount API") f044b318675f ("btrfs: handle the ro->rw transition for mounting different subvolumes") 3bb17a25bcb0 ("btrfs: add get_tree callback for new mount API") eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") 0f85e244dfc5 ("btrfs: add fs context handling functions") 17b3612022fe ("btrfs: add parse_param callback for the new mount API") 15ddcdd34ebf ("btrfs: add fs_parameter definitions") a6a8f22a4af6 ("btrfs: move space cache settings into open_ctree") 2b41b19dd6d0 ("btrfs: split out the mount option validation code into its own helper") 3c0e918b8fb3 ("btrfs: remove no longer used EXTENT_MAP_DELALLOC block start value") 7dc66abb5a47 ("btrfs: use a dedicated data structure for chunk maps") 2ecec0d6a5b5 ("btrfs: unexport extent_map_block_end()") 3128b548c759 ("btrfs: split assert into two different asserts when removing block group") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 69313850dce33ce8c24b38576a279421f4c60996 Mon Sep 17 00:00:00 2001 From: Luca Stefani <luca.stefani.ge1(a)gmail.com> Date: Tue, 17 Sep 2024 22:33:05 +0200 Subject: [PATCH] btrfs: add cancellation points to trim loops There are reports that system cannot suspend due to running trim because the task responsible for trimming the device isn't able to finish in time, especially since we have a free extent discarding phase, which can trim a lot of unallocated space. There are no limits on the trim size (unlike the block group part). Since trime isn't a critical call it can be interrupted at any time, in such cases we stop the trim, report the amount of discarded bytes and return an error. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1(a)gmail.com> Reviewed-by: David Sterba <dsterba(a)suse.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 ad70548d1f72..d9f511babd89 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1316,6 +1316,11 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len, start += bytes_to_discard; bytes_left -= bytes_to_discard; *discarded_bytes += bytes_to_discard; + + if (btrfs_trim_interrupted()) { + ret = -ERESTARTSYS; + break; + } } return ret; @@ -6470,7 +6475,7 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed) start += len; *trimmed += bytes; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index eaa1dbd31352..f4bcb2530660 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -3809,7 +3809,7 @@ static int trim_no_bitmap(struct btrfs_block_group *block_group, if (async && *total_trimmed) break; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } @@ -4000,7 +4000,7 @@ static int trim_bitmaps(struct btrfs_block_group *block_group, } block_group->discard_cursor = start; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { if (start != offset) reset_trimming_bitmap(ctl, offset); ret = -ERESTARTSYS; diff --git a/fs/btrfs/free-space-cache.h b/fs/btrfs/free-space-cache.h index 83774bfd7b3b..9f1dbfdee8ca 100644 --- a/fs/btrfs/free-space-cache.h +++ b/fs/btrfs/free-space-cache.h @@ -10,6 +10,7 @@ #include <linux/list.h> #include <linux/spinlock.h> #include <linux/mutex.h> +#include <linux/freezer.h> #include "fs.h" struct inode; @@ -56,6 +57,11 @@ static inline bool btrfs_free_space_trimming_bitmap( return (info->trim_state == BTRFS_TRIM_STATE_TRIMMING); } +static inline bool btrfs_trim_interrupted(void) +{ + return fatal_signal_pending(current) || freezing(current); +} + /* * Deltas are an effective way to populate global statistics. Give macro names * to make it clear what we're doing. An example is discard_extents in

1 week

1
0
0 0

FAILED: patch "[PATCH] btrfs: add cancellation points to trim loops" 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 69313850dce33ce8c24b38576a279421f4c60996 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101413-famine-default-fecd@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 69313850dce3 ("btrfs: add cancellation points to trim loops") a99fcb015897 ("btrfs: split remaining space to discard in chunks") 602035d7fecf ("btrfs: add forward declarations and headers, part 2") 22b46bdc5f11 ("btrfs: add forward declarations and headers, part 1") 2b712e3bb2c4 ("btrfs: remove unused included headers") f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type") 1a9fb16c6052 ("btrfs: avoid useless rbtree iterations when attempting to merge extent map") ad21f15b0f79 ("btrfs: switch to the new mount API") f044b318675f ("btrfs: handle the ro->rw transition for mounting different subvolumes") 3bb17a25bcb0 ("btrfs: add get_tree callback for new mount API") eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") 0f85e244dfc5 ("btrfs: add fs context handling functions") 17b3612022fe ("btrfs: add parse_param callback for the new mount API") 15ddcdd34ebf ("btrfs: add fs_parameter definitions") a6a8f22a4af6 ("btrfs: move space cache settings into open_ctree") 2b41b19dd6d0 ("btrfs: split out the mount option validation code into its own helper") 3c0e918b8fb3 ("btrfs: remove no longer used EXTENT_MAP_DELALLOC block start value") 7dc66abb5a47 ("btrfs: use a dedicated data structure for chunk maps") 2ecec0d6a5b5 ("btrfs: unexport extent_map_block_end()") 3128b548c759 ("btrfs: split assert into two different asserts when removing block group") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 69313850dce33ce8c24b38576a279421f4c60996 Mon Sep 17 00:00:00 2001 From: Luca Stefani <luca.stefani.ge1(a)gmail.com> Date: Tue, 17 Sep 2024 22:33:05 +0200 Subject: [PATCH] btrfs: add cancellation points to trim loops There are reports that system cannot suspend due to running trim because the task responsible for trimming the device isn't able to finish in time, especially since we have a free extent discarding phase, which can trim a lot of unallocated space. There are no limits on the trim size (unlike the block group part). Since trime isn't a critical call it can be interrupted at any time, in such cases we stop the trim, report the amount of discarded bytes and return an error. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1(a)gmail.com> Reviewed-by: David Sterba <dsterba(a)suse.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 ad70548d1f72..d9f511babd89 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1316,6 +1316,11 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len, start += bytes_to_discard; bytes_left -= bytes_to_discard; *discarded_bytes += bytes_to_discard; + + if (btrfs_trim_interrupted()) { + ret = -ERESTARTSYS; + break; + } } return ret; @@ -6470,7 +6475,7 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed) start += len; *trimmed += bytes; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index eaa1dbd31352..f4bcb2530660 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -3809,7 +3809,7 @@ static int trim_no_bitmap(struct btrfs_block_group *block_group, if (async && *total_trimmed) break; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } @@ -4000,7 +4000,7 @@ static int trim_bitmaps(struct btrfs_block_group *block_group, } block_group->discard_cursor = start; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { if (start != offset) reset_trimming_bitmap(ctl, offset); ret = -ERESTARTSYS; diff --git a/fs/btrfs/free-space-cache.h b/fs/btrfs/free-space-cache.h index 83774bfd7b3b..9f1dbfdee8ca 100644 --- a/fs/btrfs/free-space-cache.h +++ b/fs/btrfs/free-space-cache.h @@ -10,6 +10,7 @@ #include <linux/list.h> #include <linux/spinlock.h> #include <linux/mutex.h> +#include <linux/freezer.h> #include "fs.h" struct inode; @@ -56,6 +57,11 @@ static inline bool btrfs_free_space_trimming_bitmap( return (info->trim_state == BTRFS_TRIM_STATE_TRIMMING); } +static inline bool btrfs_trim_interrupted(void) +{ + return fatal_signal_pending(current) || freezing(current); +} + /* * Deltas are an effective way to populate global statistics. Give macro names * to make it clear what we're doing. An example is discard_extents in

1 week

1
0
0 0

FAILED: patch "[PATCH] btrfs: add cancellation points to trim loops" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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-6.6.y git checkout FETCH_HEAD git cherry-pick -x 69313850dce33ce8c24b38576a279421f4c60996 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101412-diaphragm-sly-ea40@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 69313850dce3 ("btrfs: add cancellation points to trim loops") a99fcb015897 ("btrfs: split remaining space to discard in chunks") 602035d7fecf ("btrfs: add forward declarations and headers, part 2") 22b46bdc5f11 ("btrfs: add forward declarations and headers, part 1") 2b712e3bb2c4 ("btrfs: remove unused included headers") f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type") 1a9fb16c6052 ("btrfs: avoid useless rbtree iterations when attempting to merge extent map") ad21f15b0f79 ("btrfs: switch to the new mount API") f044b318675f ("btrfs: handle the ro->rw transition for mounting different subvolumes") 3bb17a25bcb0 ("btrfs: add get_tree callback for new mount API") eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") 0f85e244dfc5 ("btrfs: add fs context handling functions") 17b3612022fe ("btrfs: add parse_param callback for the new mount API") 15ddcdd34ebf ("btrfs: add fs_parameter definitions") a6a8f22a4af6 ("btrfs: move space cache settings into open_ctree") 2b41b19dd6d0 ("btrfs: split out the mount option validation code into its own helper") 3c0e918b8fb3 ("btrfs: remove no longer used EXTENT_MAP_DELALLOC block start value") 7dc66abb5a47 ("btrfs: use a dedicated data structure for chunk maps") 2ecec0d6a5b5 ("btrfs: unexport extent_map_block_end()") 3128b548c759 ("btrfs: split assert into two different asserts when removing block group") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 69313850dce33ce8c24b38576a279421f4c60996 Mon Sep 17 00:00:00 2001 From: Luca Stefani <luca.stefani.ge1(a)gmail.com> Date: Tue, 17 Sep 2024 22:33:05 +0200 Subject: [PATCH] btrfs: add cancellation points to trim loops There are reports that system cannot suspend due to running trim because the task responsible for trimming the device isn't able to finish in time, especially since we have a free extent discarding phase, which can trim a lot of unallocated space. There are no limits on the trim size (unlike the block group part). Since trime isn't a critical call it can be interrupted at any time, in such cases we stop the trim, report the amount of discarded bytes and return an error. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1(a)gmail.com> Reviewed-by: David Sterba <dsterba(a)suse.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 ad70548d1f72..d9f511babd89 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1316,6 +1316,11 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len, start += bytes_to_discard; bytes_left -= bytes_to_discard; *discarded_bytes += bytes_to_discard; + + if (btrfs_trim_interrupted()) { + ret = -ERESTARTSYS; + break; + } } return ret; @@ -6470,7 +6475,7 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed) start += len; *trimmed += bytes; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index eaa1dbd31352..f4bcb2530660 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -3809,7 +3809,7 @@ static int trim_no_bitmap(struct btrfs_block_group *block_group, if (async && *total_trimmed) break; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } @@ -4000,7 +4000,7 @@ static int trim_bitmaps(struct btrfs_block_group *block_group, } block_group->discard_cursor = start; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { if (start != offset) reset_trimming_bitmap(ctl, offset); ret = -ERESTARTSYS; diff --git a/fs/btrfs/free-space-cache.h b/fs/btrfs/free-space-cache.h index 83774bfd7b3b..9f1dbfdee8ca 100644 --- a/fs/btrfs/free-space-cache.h +++ b/fs/btrfs/free-space-cache.h @@ -10,6 +10,7 @@ #include <linux/list.h> #include <linux/spinlock.h> #include <linux/mutex.h> +#include <linux/freezer.h> #include "fs.h" struct inode; @@ -56,6 +57,11 @@ static inline bool btrfs_free_space_trimming_bitmap( return (info->trim_state == BTRFS_TRIM_STATE_TRIMMING); } +static inline bool btrfs_trim_interrupted(void) +{ + return fatal_signal_pending(current) || freezing(current); +} + /* * Deltas are an effective way to populate global statistics. Give macro names * to make it clear what we're doing. An example is discard_extents in

1 week

1
0
0 0

FAILED: patch "[PATCH] btrfs: split remaining space to discard in chunks" 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 a99fcb0158978ed332009449b484e5f3ca2d7df4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101458-lyrically-defile-5bc8@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: a99fcb015897 ("btrfs: split remaining space to discard in chunks") 29e70be261d9 ("btrfs: use SECTOR_SHIFT to convert physical offset to LBA") b7d463a1d125 ("btrfs: store a pointer to the original btrfs_bio in struct compressed_bio") 690834e47cf7 ("btrfs: pass a btrfs_bio to btrfs_submit_compressed_read") 7edb9a3e7200 ("btrfs: move zero filling of compressed read bios into common code") 32586c5bca72 ("btrfs: factor out a btrfs_free_compressed_pages helper") 10e924bc320a ("btrfs: factor out a btrfs_add_compressed_bio_pages helper") d7294e4deeb9 ("btrfs: use the bbio file offset in add_ra_bio_pages") e7aff33e3161 ("btrfs: use the bbio file offset in btrfs_submit_compressed_read") 798c9fc74d03 ("btrfs: remove redundant free_extent_map in btrfs_submit_compressed_read") 544fe4a903ce ("btrfs: embed a btrfs_bio into struct compressed_bio") d5e4377d5051 ("btrfs: split zone append bios in btrfs_submit_bio") 35a8d7da3ca8 ("btrfs: remove now spurious bio submission helpers") 285599b6fe15 ("btrfs: remove the fs_info argument to btrfs_submit_bio") 48253076c3a9 ("btrfs: open code submit_encoded_read_bio") 30493ff49f81 ("btrfs: remove stripe boundary calculation for compressed I/O") 2380220e1e13 ("btrfs: remove stripe boundary calculation for buffered I/O") 67d669825090 ("btrfs: pass the iomap bio to btrfs_submit_bio") 852eee62d31a ("btrfs: allow btrfs_submit_bio to split bios") 69ccf3f4244a ("btrfs: handle recording of zoned writes in the storage layer") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a99fcb0158978ed332009449b484e5f3ca2d7df4 Mon Sep 17 00:00:00 2001 From: Luca Stefani <luca.stefani.ge1(a)gmail.com> Date: Tue, 17 Sep 2024 22:33:04 +0200 Subject: [PATCH] btrfs: split remaining space to discard in chunks Per Qu Wenruo in case we have a very large disk, e.g. 8TiB device, mostly empty although we will do the split according to our super block locations, the last super block ends at 256G, we can submit a huge discard for the range [256G, 8T), causing a large delay. Split the space left to discard based on BTRFS_MAX_DISCARD_CHUNK_SIZE in preparation of introduction of cancellation points to trim. The value of the chunk size is arbitrary, it can be higher or derived from actual device capabilities but we can't easily read that using bio_discard_limit(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1(a)gmail.com> Reviewed-by: David Sterba <dsterba(a)suse.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 a5966324607d..ad70548d1f72 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1300,13 +1300,24 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len, bytes_left = end - start; } - if (bytes_left) { + while (bytes_left) { + u64 bytes_to_discard = min(BTRFS_MAX_DISCARD_CHUNK_SIZE, bytes_left); + ret = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, - bytes_left >> SECTOR_SHIFT, + bytes_to_discard >> SECTOR_SHIFT, GFP_NOFS); - if (!ret) - *discarded_bytes += bytes_left; + + if (ret) { + if (ret != -EOPNOTSUPP) + break; + continue; + } + + start += bytes_to_discard; + bytes_left -= bytes_to_discard; + *discarded_bytes += bytes_to_discard; } + return ret; } diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h index 03d2d60afe0c..4481575dd70f 100644 --- a/fs/btrfs/volumes.h +++ b/fs/btrfs/volumes.h @@ -30,6 +30,12 @@ struct btrfs_zoned_device_info; #define BTRFS_MAX_DATA_CHUNK_SIZE (10ULL * SZ_1G) +/* + * Arbitratry maximum size of one discard request to limit potentially long time + * spent in blkdev_issue_discard(). + */ +#define BTRFS_MAX_DISCARD_CHUNK_SIZE (SZ_1G) + extern struct mutex uuid_mutex; #define BTRFS_STRIPE_LEN SZ_64K

1 week

1
0
0 0

FAILED: patch "[PATCH] btrfs: split remaining space to discard in chunks" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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-6.1.y git checkout FETCH_HEAD git cherry-pick -x a99fcb0158978ed332009449b484e5f3ca2d7df4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024101454-pouncing-unrobed-994a@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: a99fcb015897 ("btrfs: split remaining space to discard in chunks") 29e70be261d9 ("btrfs: use SECTOR_SHIFT to convert physical offset to LBA") b7d463a1d125 ("btrfs: store a pointer to the original btrfs_bio in struct compressed_bio") 690834e47cf7 ("btrfs: pass a btrfs_bio to btrfs_submit_compressed_read") 7edb9a3e7200 ("btrfs: move zero filling of compressed read bios into common code") 32586c5bca72 ("btrfs: factor out a btrfs_free_compressed_pages helper") 10e924bc320a ("btrfs: factor out a btrfs_add_compressed_bio_pages helper") d7294e4deeb9 ("btrfs: use the bbio file offset in add_ra_bio_pages") e7aff33e3161 ("btrfs: use the bbio file offset in btrfs_submit_compressed_read") 798c9fc74d03 ("btrfs: remove redundant free_extent_map in btrfs_submit_compressed_read") 544fe4a903ce ("btrfs: embed a btrfs_bio into struct compressed_bio") d5e4377d5051 ("btrfs: split zone append bios in btrfs_submit_bio") 35a8d7da3ca8 ("btrfs: remove now spurious bio submission helpers") 285599b6fe15 ("btrfs: remove the fs_info argument to btrfs_submit_bio") 48253076c3a9 ("btrfs: open code submit_encoded_read_bio") 30493ff49f81 ("btrfs: remove stripe boundary calculation for compressed I/O") 2380220e1e13 ("btrfs: remove stripe boundary calculation for buffered I/O") 67d669825090 ("btrfs: pass the iomap bio to btrfs_submit_bio") 852eee62d31a ("btrfs: allow btrfs_submit_bio to split bios") 69ccf3f4244a ("btrfs: handle recording of zoned writes in the storage layer") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a99fcb0158978ed332009449b484e5f3ca2d7df4 Mon Sep 17 00:00:00 2001 From: Luca Stefani <luca.stefani.ge1(a)gmail.com> Date: Tue, 17 Sep 2024 22:33:04 +0200 Subject: [PATCH] btrfs: split remaining space to discard in chunks Per Qu Wenruo in case we have a very large disk, e.g. 8TiB device, mostly empty although we will do the split according to our super block locations, the last super block ends at 256G, we can submit a huge discard for the range [256G, 8T), causing a large delay. Split the space left to discard based on BTRFS_MAX_DISCARD_CHUNK_SIZE in preparation of introduction of cancellation points to trim. The value of the chunk size is arbitrary, it can be higher or derived from actual device capabilities but we can't easily read that using bio_discard_limit(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1(a)gmail.com> Reviewed-by: David Sterba <dsterba(a)suse.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 a5966324607d..ad70548d1f72 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1300,13 +1300,24 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len, bytes_left = end - start; } - if (bytes_left) { + while (bytes_left) { + u64 bytes_to_discard = min(BTRFS_MAX_DISCARD_CHUNK_SIZE, bytes_left); + ret = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, - bytes_left >> SECTOR_SHIFT, + bytes_to_discard >> SECTOR_SHIFT, GFP_NOFS); - if (!ret) - *discarded_bytes += bytes_left; + + if (ret) { + if (ret != -EOPNOTSUPP) + break; + continue; + } + + start += bytes_to_discard; + bytes_left -= bytes_to_discard; + *discarded_bytes += bytes_to_discard; } + return ret; } diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h index 03d2d60afe0c..4481575dd70f 100644 --- a/fs/btrfs/volumes.h +++ b/fs/btrfs/volumes.h @@ -30,6 +30,12 @@ struct btrfs_zoned_device_info; #define BTRFS_MAX_DATA_CHUNK_SIZE (10ULL * SZ_1G) +/* + * Arbitratry maximum size of one discard request to limit potentially long time + * spent in blkdev_issue_discard(). + */ +#define BTRFS_MAX_DISCARD_CHUNK_SIZE (SZ_1G) + extern struct mutex uuid_mutex; #define BTRFS_STRIPE_LEN SZ_64K

1 week

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024