mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Luca Stefani <luca.stefani.ge1@gmail.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: Don't block system suspend during fstrim
Date: Mon, 2 Sep 2024 10:32:29 +0200	[thread overview]
Message-ID: <400d2855-59c2-47d2-9224-f76f219ae993@gmail.com> (raw)
In-Reply-To: <20240822164908.4957-1-luca.stefani.ge1@gmail.com>

Any update on this? It's not critical but I'd like to know if it's in 
some part proper.
Thanks, Luca.
> Sometimes the system isn't able to suspend because
> the task responsible for trimming the device isn't
> able to finish in time.
>
> Since discard isn't a critical call it can be interrupted
> at any time, we can simply report the amount of discarded
> bytes in such cases and stop the trim.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219180
> Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
> ---
> I have no idea if that's correct, just something I implemented
> looking at the same solution made in ext4 by 5229a658f645.
>
> The patch in itself seems to solve the issue.
>
> repro is as follows:
> sudo /sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported &
> sudo ./sleepgraph.py -m mem -rtcwake 5
>
> [836563.289069] PM: suspend exit
> [836563.909298] PM: suspend entry (s2idle)
> [836563.935447] Filesystems sync: 0.026 seconds
> [836563.951391] Freezing user space processes
> [836583.958957] Freezing user space processes failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
> [836583.959582] task:fstrim          state:D stack:0     pid:241865 tgid:241865 ppid:241864 flags:0x00004006
> [836583.959592] Call Trace:
> [836583.959595]  <TASK>
> [836583.959600]  __schedule+0x400/0x1720
> [836583.959612]  ? mod_delayed_work_on+0xa4/0xb0
> [836583.959622]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959628]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959631]  ? blk_mq_flush_plug_list.part.0+0x1e3/0x610
> [836583.959640]  schedule+0x27/0xf0
> [836583.959644]  schedule_timeout+0x12f/0x160
> [836583.959652]  io_schedule_timeout+0x51/0x70
> [836583.959657]  wait_for_completion_io+0x8a/0x160
> [836583.959663]  submit_bio_wait+0x60/0x90
> [836583.959671]  blkdev_issue_discard+0x91/0x100
> [836583.959680]  btrfs_issue_discard+0xc4/0x140
> [836583.959689]  btrfs_discard_extent+0x241/0x2a0
> [836583.959695]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959702]  do_trimming+0xd2/0x240
> [836583.959712]  trim_bitmaps+0x350/0x4c0
> [836583.959723]  btrfs_trim_block_group+0xb8/0x110
> [836583.959729]  btrfs_trim_fs+0x118/0x440
> [836583.959734]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959738]  ? security_capable+0x41/0x70
> [836583.959746]  btrfs_ioctl_fitrim+0x113/0x180
> [836583.959752]  btrfs_ioctl+0xdaf/0x2670
> [836583.959759]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959763]  ? ioctl_has_perm.constprop.0.isra.0+0xd8/0x130
> [836583.959774]  __x64_sys_ioctl+0x94/0xd0
> [836583.959782]  do_syscall_64+0x82/0x160
> [836583.959790]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959793]  ? syscall_exit_to_user_mode+0x72/0x220
> [836583.959799]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959802]  ? do_syscall_64+0x8e/0x160
> [836583.959807]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959811]  ? do_sys_openat2+0x9c/0xe0
> [836583.959821]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959825]  ? syscall_exit_to_user_mode+0x72/0x220
> [836583.959828]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959832]  ? do_syscall_64+0x8e/0x160
> [836583.959835]  ? syscall_exit_to_user_mode+0x72/0x220
> [836583.959838]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959842]  ? do_syscall_64+0x8e/0x160
> [836583.959845]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959849]  ? do_syscall_64+0x8e/0x160
> [836583.959851]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959855]  ? do_syscall_64+0x8e/0x160
> [836583.959858]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959861]  ? do_syscall_64+0x8e/0x160
> [836583.959864]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959868]  ? srso_alias_return_thunk+0x5/0xfbef5
> [836583.959873]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [836583.959878] RIP: 0033:0x7f3e4261af2d
> [836583.959944] RSP: 002b:00007ffec002f400 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [836583.959950] RAX: ffffffffffffffda RBX: 00007ffec002f570 RCX: 00007f3e4261af2d
> [836583.959952] RDX: 00007ffec002f470 RSI: 00000000c0185879 RDI: 0000000000000003
> [836583.959955] RBP: 00007ffec002f450 R08: 0000562d74da7010 R09: 00007ffec002e7f2
> [836583.959957] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562d74daafc0
> [836583.959960] R13: 0000000000000003 R14: 0000562d74daa970 R15: 0000562d74daad40
> [836583.959967]  </TASK>
> ---
>   fs/btrfs/extent-tree.c | 20 ++++++++++++++++----
>   1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index feec49e6f9c8..7e4c1d4f2f7c 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -16,6 +16,7 @@
>   #include <linux/percpu_counter.h>
>   #include <linux/lockdep.h>
>   #include <linux/crc32c.h>
> +#include <linux/freezer.h>
>   #include "ctree.h"
>   #include "extent-tree.h"
>   #include "transaction.h"
> @@ -6361,6 +6362,11 @@ void btrfs_error_unpin_extent_range(struct btrfs_fs_info *fs_info, u64 start, u6
>   	unpin_extent_range(fs_info, start, end, false);
>   }
>   
> +static bool btrfs_trim_interrupted(void)
> +{
> +	return fatal_signal_pending(current) || freezing(current);
> +}
> +
>   /*
>    * It used to be that old block groups would be left around forever.
>    * Iterating over them would be enough to trim unused space.  Since we
> @@ -6459,8 +6465,8 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed)
>   		start += len;
>   		*trimmed += bytes;
>   
> -		if (fatal_signal_pending(current)) {
> -			ret = -ERESTARTSYS;
> +		if (btrfs_trim_interrupted()) {
> +			ret = 0;
>   			break;
>   		}
>   
> @@ -6508,6 +6514,9 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
>   
>   	cache = btrfs_lookup_first_block_group(fs_info, range->start);
>   	for (; cache; cache = btrfs_next_block_group(cache)) {
> +		if (btrfs_trim_interrupted())
> +			break;
> +
>   		if (cache->start >= range_end) {
>   			btrfs_put_block_group(cache);
>   			break;
> @@ -6547,17 +6556,20 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
>   
>   	mutex_lock(&fs_devices->device_list_mutex);
>   	list_for_each_entry(device, &fs_devices->devices, dev_list) {
> +		if (btrfs_trim_interrupted())
> +			break;
> +
>   		if (test_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state))
>   			continue;
>   
>   		ret = btrfs_trim_free_extents(device, &group_trimmed);
> +
> +		trimmed += group_trimmed;
>   		if (ret) {
>   			dev_failed++;
>   			dev_ret = ret;
>   			break;
>   		}
> -
> -		trimmed += group_trimmed;
>   	}
>   	mutex_unlock(&fs_devices->device_list_mutex);
>   

  reply	other threads:[~2024-09-02  8:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-22 16:48 Luca Stefani
2024-09-02  8:32 ` Luca Stefani [this message]
2024-09-02  8:49   ` Qu Wenruo
     [not found]     ` <CAO0HQ0X3zk6aau50Ew2nmNP-pwNEkmgAoC2Ewmi30sGi7uQwDA@mail.gmail.com>
2024-09-02  9:12       ` Qu Wenruo
2024-09-02  9:17         ` Qu Wenruo
2024-09-02  9:31           ` Luca Stefani
2024-09-02  9:40             ` Qu Wenruo
2024-09-02 11:01           ` Qu Wenruo
2024-09-02 11:10             ` Luca Stefani
2024-09-02  9:14     ` Luca Stefani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=400d2855-59c2-47d2-9224-f76f219ae993@gmail.com \
    --to=luca.stefani.ge1@gmail.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®