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.”
next prev parent 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).