Commit 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole
filesystem) makes sure we always trim starting from the first block group.
However it also removed the range.start validity check which is set in the
context of the user, where its range is from 0 to maximum of filesystem
totalbytes and so we have to check its validity in the kernel.

Also as in the fstrim(8) [1] the kernel layers may modify the trim range.

[1]
Further, the kernel block layer reserves the right to adjust the discard
ranges to fit raid stripe geometry, non-trim capable devices in a LVM
setup, etc. These reductions would not be reflected in fstrim_range.len
(the --length option).

This patch undos the deleted range::start validity check.

Fixes: 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole filesystem)
Signed-off-by: Anand Jain <anand.j...@oracle.com>
---
  With this patch fstests generic/260 is successful now.

 fs/btrfs/ioctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index b431f7877e88..9345fcdf80c7 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -521,6 +521,8 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, 
void __user *arg)
                return -EOPNOTSUPP;
        if (copy_from_user(&range, arg, sizeof(range)))
                return -EFAULT;
+       if (range.start > btrfs_super_total_bytes(fs_info->super_copy))
+               return -EINVAL;
 
        /*
         * NOTE: Don't truncate the range using super->total_bytes.  Bytenr of
-- 
2.21.0 (Apple Git-120)

Reply via email to