linux-kernel - Re: [PATCH] btrfs: Don't block system suspend during fstrim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2e72f744-7262-4d22-a3a1-44a323036ec9@suse.com>
Date: Mon, 2 Sep 2024 19:10:57 +0930
From: Qu Wenruo <wqu@...e.com>
To: Luca Stefani <luca.stefani.ge1@...il.com>,
 Qu Wenruo <quwenruo.btrfs@....com>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
 David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: Don't block system suspend during fstrim



在 2024/9/2 19:01, Luca Stefani 写道:
[...]
>>>
>>> Oh, then it's fine.
>>>
>>> Except the return code, everything looks fine to me now.
>>
>> Forgot to mention that, even for error case, we should copy the 
>> fstrim_range structure to the ioctl parameter to indicate any progress 
>> we made.
> This seems to be already the case.
> range->len = trimmed; is always executed regardless of previous failures
> and there doesn't seem to be any early return.

What I mean is inside btrfs_ioctl_fitrim(), at the end if 
btrfs_trim_fs() returned error (including interrupted), copy_to_user() 
will not be call, that's the problem needs to be solved, as long as we 
return error for interrupted cases.

Thanks,
Qu
> 
> Will try adding back the errno and try the repro.
> 
> Thanks.
>>
>> Thanks,
>> Qu
>>>
>>> Just please update the commit message to explicitly mention that, 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).
>>>
>>> Thanks,
>>> Qu
>>>>
>>>>     Thanks,
>>>>     Qu
>>>>
>>>>      >>       }
>>>>      >>       mutex_unlock(&fs_devices->device_list_mutex);
>>>>      >
>>>>
>>>
>