Re: [PATCH] btrfs: do not leak -ERESTARTSYS from FITRIM to userspace

From: Qu Wenruo

Date: Wed Oct 28 2026 - 05:47:41 EST



在 2026/10/28 20:12, Qu Wenruo 写道:


在 2026/10/28 19:50, Luca Stefani 写道:
On Wed, 28 Oct 2026 at 09:57, Qu Wenruo <wqu@xxxxxxxx> wrote:
[...]
I don't know what the intention of btrfs: handle user interrupt
properly in btrfs_trim_fs()
was, maybe we should just swallow the ERESTARTSYS case in those scenarios.

I agree on that btrfs is the exception, we should follow ext4/xfs, not
rely on some tricky signal handling behavior for suspension.
When I updated btrfs_trim_interrupted I used the same "checks" as
seen in ext4 so at least on that part it's identical.

What differs is our error handling: we set/handle -ERESTARTSYS, ext4 does not.
ext4_try_to_trim_range only ever succeeds by returning the count of
trimmed bytes
even if it checks for trim interruptions.

I think if we remove ret = -ERESTARTSYS; from the
btrfs_trim_interrupted branches
we'd align the behavior (plus reverting the previous change as that's
now useless)

I think that's would work for most call sites, but there are some call sites that we may want to know if it's interrupted.

E.g. btrfs_issue_discard() is very deep inside all trim calls, if we drop the return value without any other extra way to notify the caller, it will incorrectly return 0, which is definitely not a good idea.

A safer solution would be keep the existing ERESTARTSYS, but change it to return 0 for now.

Sorry, I mean to return 0 at the fstrim entrance, btrfs_trim_fs().


But if you have a better solution and can completely remove ERESTARTSYS, I can't be more happier.

Thanks,
Qu