* [PATCH 6.6.x] btrfs: add cancellation points to trim loops
@ 2024-11-25 18:07 David Sterba
2024-12-02 11:15 ` Greg KH
0 siblings, 1 reply; 5+ messages in thread
From: David Sterba @ 2024-11-25 18:07 UTC (permalink / raw)
To: stable; +Cc: linux-btrfs, git, Luca Stefani, David Sterba
From: Luca Stefani <luca.stefani.ge1@gmail.com>
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@vger.kernel.org # 5.15+
Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
---
fs/btrfs/extent-tree.c | 7 ++++++-
fs/btrfs/free-space-cache.c | 4 ++--
fs/btrfs/free-space-cache.h | 7 +++++++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index b3680e1c7054..599407120513 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1319,6 +1319,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;
@@ -6094,7 +6099,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 3bcf4a30cad7..9a6ec9344c3e 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -3808,7 +3808,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;
}
@@ -3999,7 +3999,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 33b4da3271b1..bd80c7b2af96 100644
--- a/fs/btrfs/free-space-cache.h
+++ b/fs/btrfs/free-space-cache.h
@@ -6,6 +6,8 @@
#ifndef BTRFS_FREE_SPACE_CACHE_H
#define BTRFS_FREE_SPACE_CACHE_H
+#include <linux/freezer.h>
+
/*
* This is the trim state of an extent or bitmap.
*
@@ -43,6 +45,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
--
2.45.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH 6.6.x] btrfs: add cancellation points to trim loops
2024-11-25 18:07 [PATCH 6.6.x] btrfs: add cancellation points to trim loops David Sterba
@ 2024-12-02 11:15 ` Greg KH
2024-12-03 15:27 ` David Sterba
0 siblings, 1 reply; 5+ messages in thread
From: Greg KH @ 2024-12-02 11:15 UTC (permalink / raw)
To: David Sterba; +Cc: stable, linux-btrfs, git, Luca Stefani
On Mon, Nov 25, 2024 at 07:07:28PM +0100, David Sterba wrote:
> From: Luca Stefani <luca.stefani.ge1@gmail.com>
>
> 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@vger.kernel.org # 5.15+
> Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
> Reviewed-by: David Sterba <dsterba@suse.com>
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
No git id? :(
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 6.6.x] btrfs: add cancellation points to trim loops
2024-12-02 11:15 ` Greg KH
@ 2024-12-03 15:27 ` David Sterba
2024-12-03 15:41 ` David Sterba
0 siblings, 1 reply; 5+ messages in thread
From: David Sterba @ 2024-12-03 15:27 UTC (permalink / raw)
To: Greg KH; +Cc: David Sterba, stable, linux-btrfs, git, Luca Stefani
On Mon, Dec 02, 2024 at 12:15:54PM +0100, Greg KH wrote:
> On Mon, Nov 25, 2024 at 07:07:28PM +0100, David Sterba wrote:
> > From: Luca Stefani <luca.stefani.ge1@gmail.com>
> >
> > 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@vger.kernel.org # 5.15+
> > Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
> > Reviewed-by: David Sterba <dsterba@suse.com>
> > Signed-off-by: David Sterba <dsterba@suse.com>
> > ---
>
> No git id? :(
I forgot to add it but meanwhile Sasha looked up the commit and added it for me.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 6.6.x] btrfs: add cancellation points to trim loops
2024-12-03 15:27 ` David Sterba
@ 2024-12-03 15:41 ` David Sterba
2024-12-06 12:37 ` Greg KH
0 siblings, 1 reply; 5+ messages in thread
From: David Sterba @ 2024-12-03 15:41 UTC (permalink / raw)
To: Greg KH; +Cc: David Sterba, stable, linux-btrfs, git, Luca Stefani
On Tue, Dec 03, 2024 at 04:27:56PM +0100, David Sterba wrote:
> On Mon, Dec 02, 2024 at 12:15:54PM +0100, Greg KH wrote:
> > On Mon, Nov 25, 2024 at 07:07:28PM +0100, David Sterba wrote:
> > > From: Luca Stefani <luca.stefani.ge1@gmail.com>
> > >
> > > 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@vger.kernel.org # 5.15+
> > > Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
> > > Reviewed-by: David Sterba <dsterba@suse.com>
> > > Signed-off-by: David Sterba <dsterba@suse.com>
> > > ---
> >
> > No git id? :(
>
> I forgot to add it but meanwhile Sasha looked up the commit and added it for me.
For the record it's 69313850dce33ce8c24b38576a279421f4c60996
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 6.6.x] btrfs: add cancellation points to trim loops
2024-12-03 15:41 ` David Sterba
@ 2024-12-06 12:37 ` Greg KH
0 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2024-12-06 12:37 UTC (permalink / raw)
To: David Sterba; +Cc: David Sterba, stable, linux-btrfs, git, Luca Stefani
On Tue, Dec 03, 2024 at 04:41:59PM +0100, David Sterba wrote:
> On Tue, Dec 03, 2024 at 04:27:56PM +0100, David Sterba wrote:
> > On Mon, Dec 02, 2024 at 12:15:54PM +0100, Greg KH wrote:
> > > On Mon, Nov 25, 2024 at 07:07:28PM +0100, David Sterba wrote:
> > > > From: Luca Stefani <luca.stefani.ge1@gmail.com>
> > > >
> > > > 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@vger.kernel.org # 5.15+
> > > > Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
> > > > Reviewed-by: David Sterba <dsterba@suse.com>
> > > > Signed-off-by: David Sterba <dsterba@suse.com>
> > > > ---
> > >
> > > No git id? :(
> >
> > I forgot to add it but meanwhile Sasha looked up the commit and added it for me.
>
> For the record it's 69313850dce33ce8c24b38576a279421f4c60996
Great, can you resend it with that information?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-12-06 12:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-25 18:07 [PATCH 6.6.x] btrfs: add cancellation points to trim loops David Sterba
2024-12-02 11:15 ` Greg KH
2024-12-03 15:27 ` David Sterba
2024-12-03 15:41 ` David Sterba
2024-12-06 12:37 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox