linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>, Qu Wenruo <wqu@suse.com>
Subject: Re: [PATCH] btrfs: trim: fix range start validity check
Date: Wed, 7 Aug 2019 09:44:33 +0100	[thread overview]
Message-ID: <CAL3q7H7WRPuFNh3+534kF7SgLe0NmQAwCejfW9DJgasXfkQ1qQ@mail.gmail.com> (raw)
In-Reply-To: <20190807082054.1922-1-anand.jain@oracle.com>

On Wed, Aug 7, 2019 at 9:35 AM Anand Jain <anand.jain@oracle.com> wrote:
>
> 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.jain@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;

This makes it impossible to trim block groups that start at an offset
greater then the super_total_bytes values. In fact, in extreme cases
it's possible all block groups start at offsets larger then
super_total_bytes.
Have you considered that, or am I missing something?

The change log is also vague to me, doesn't explain why you are
re-adding that check.

Thanks.

>
>         /*
>          * NOTE: Don't truncate the range using super->total_bytes.  Bytenr of
> --
> 2.21.0 (Apple Git-120)
>


-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

  reply	other threads:[~2019-08-07  8:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07  8:20 [PATCH] btrfs: trim: fix range start validity check Anand Jain
2019-08-07  8:44 ` Filipe Manana [this message]
2019-08-07  8:55   ` Qu Wenruo
2019-08-07  9:43     ` Anand Jain
2019-08-07 11:15       ` Qu Wenruo
2019-08-08  3:53         ` Anand Jain
2019-08-08  5:55           ` Qu Wenruo
2019-08-08  8:34             ` Anand Jain
2019-08-08  8:40               ` Qu Wenruo

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=CAL3q7H7WRPuFNh3+534kF7SgLe0NmQAwCejfW9DJgasXfkQ1qQ@mail.gmail.com \
    --to=fdmanana@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /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;
as well as URLs for NNTP newsgroup(s).