| Message ID | 20240917203346.9670-3-luca.stefani.ge1@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: Don't block system suspend during fstrim | expand |
Hi, forgive my ignorance of the kernel patch workflow but it appears this second patch was only ported to 6.11? Only the first patch here was ported to LTS kernels (i.e. f00545e8386e228aac739588b40a6f200e0f0ffc). I just hit the bug this fixes on 6.6.59 (I need to update, I know) but also checked Greg's v6.6.62 tree and it's not in there either. Thanks, Atemu
On Tue, Nov 19, 2024 at 07:54:58AM +0000, git@atemu.net wrote: > Hi, > > forgive my ignorance of the kernel patch workflow but it appears this second patch was only ported to 6.11? Only the first patch here was ported to LTS kernels (i.e. f00545e8386e228aac739588b40a6f200e0f0ffc). > > I just hit the bug this fixes on 6.6.59 (I need to update, I know) but also checked Greg's v6.6.62 tree and it's not in there either. What is the git commit id in LInus's tree you are referring to here? thanks, greg k-h
Hi,
> What is the git commit id in LInus's tree you are referring to here?
It's 69313850dce33ce8c24b38576a279421f4c60996. Apparently marked for backport to 5.15+.
Thanks,
Atemu
On Wed, Nov 20, 2024 at 07:41:32AM +0000, Atemu wrote: > Hi, > > > > What is the git commit id in LInus's tree you are referring to here? > > It's 69313850dce33ce8c24b38576a279421f4c60996. Apparently marked for backport to 5.15+. Please see the FAILED emails about why this was not applied, here is one: https://lore.kernel.org/r/2024101412-diaphragm-sly-ea40@gregkh Have you tested and tried this commit out in these older kernels? If so, can you please send a working version so that we can apply them? thanks, greg k-h
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
Sometimes the system isn't able to suspend 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, and there is no limits on the trim size (unlike the block group part). Since discard 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 failure. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com> --- fs/btrfs/extent-tree.c | 7 ++++++- fs/btrfs/free-space-cache.c | 4 ++-- fs/btrfs/free-space-cache.h | 6 ++++++ 3 files changed, 14 insertions(+), 3 deletions(-)