From: Jan Kara <jack@suse.cz>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: linux-ext4@vger.kernel.org, jack@suse.cz, tytso@mit.edu,
adilger@dilger.ca, darrick.wong@oracle.com, hch@infradead.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Dan Carpenter <dan.carpenter@oracle.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Murphy Zhou <jencce.kernel@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org
Subject: Re: [PATCH 5/5] ext4: Get rid of ext4_fiemap_check_ranges
Date: Thu, 23 Apr 2020 13:20:14 +0200 [thread overview]
Message-ID: <20200423112014.GL3737@quack2.suse.cz> (raw)
In-Reply-To: <b2edd7710f07d94101a6055e398a5e4ed01f09bf.1587555962.git.riteshh@linux.ibm.com>
On Thu 23-04-20 16:17:57, Ritesh Harjani wrote:
> Now that fiemap_check_ranges() is available for other filesystems
> to use, so get rid of ext4's private version.
>
> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Nice. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/ext4/ioctl.c | 25 +------------------------
> 1 file changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 76a2b5200ba3..6a7d7e9027cd 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -733,29 +733,6 @@ static void ext4_fill_fsxattr(struct inode *inode, struct fsxattr *fa)
> fa->fsx_projid = from_kprojid(&init_user_ns, ei->i_projid);
> }
>
> -/* copied from fs/ioctl.c */
> -static int ext4_fiemap_check_ranges(struct super_block *sb,
> - u64 start, u64 len, u64 *new_len)
> -{
> - u64 maxbytes = (u64) sb->s_maxbytes;
> -
> - *new_len = len;
> -
> - if (len == 0)
> - return -EINVAL;
> -
> - if (start > maxbytes)
> - return -EFBIG;
> -
> - /*
> - * Shrink request scope to what the fs can actually handle.
> - */
> - if (len > maxbytes || (maxbytes - len) < start)
> - *new_len = maxbytes - start;
> -
> - return 0;
> -}
> -
> /* So that the fiemap access checks can't overflow on 32 bit machines. */
> #define FIEMAP_MAX_EXTENTS (UINT_MAX / sizeof(struct fiemap_extent))
>
> @@ -775,7 +752,7 @@ static int ext4_ioctl_get_es_cache(struct file *filp, unsigned long arg)
> if (fiemap.fm_extent_count > FIEMAP_MAX_EXTENTS)
> return -EINVAL;
>
> - error = ext4_fiemap_check_ranges(sb, fiemap.fm_start, fiemap.fm_length,
> + error = fiemap_check_ranges(sb, fiemap.fm_start, fiemap.fm_length,
> &len);
> if (error)
> return error;
> --
> 2.21.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2020-04-23 11:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 10:47 [PATCH 0/5] ext4/overlayfs: fiemap related fixes Ritesh Harjani
2020-04-23 10:47 ` [PATCH 1/5] ext4: Fix EXT4_MAX_LOGICAL_BLOCK macro Ritesh Harjani
2020-04-23 11:16 ` Jan Kara
2020-04-23 10:47 ` [PATCH 2/5] ext4: Rename fiemap_check_ranges() to make it ext4 specific Ritesh Harjani
2020-04-23 11:17 ` Jan Kara
2020-04-23 10:47 ` [PATCH 3/5] vfs: EXPORT_SYMBOL for fiemap_check_ranges() Ritesh Harjani
2020-04-23 11:18 ` Jan Kara
2020-04-23 10:47 ` [PATCH 4/5] overlayfs: Check for range bounds before calling i_op->fiemap() Ritesh Harjani
2020-04-23 11:19 ` Jan Kara
2020-04-25 8:54 ` Amir Goldstein
2020-04-23 10:47 ` [PATCH 5/5] ext4: Get rid of ext4_fiemap_check_ranges Ritesh Harjani
2020-04-23 11:20 ` Jan Kara [this message]
2020-04-24 10:11 ` [PATCH 0/5] ext4/overlayfs: fiemap related fixes Christoph Hellwig
2020-04-24 23:20 ` Ritesh Harjani
2020-04-25 9:11 ` Amir Goldstein
2020-04-25 9:43 ` Christoph Hellwig
2020-04-25 10:49 ` Amir Goldstein
2020-04-25 11:14 ` Ritesh Harjani
2020-04-27 6:28 ` Christoph Hellwig
2020-04-27 10:15 ` Amir Goldstein
2020-04-27 10:38 ` Christoph Hellwig
2020-04-25 17:32 ` Andreas Dilger
2020-04-27 6:42 ` Christoph Hellwig
2020-04-25 9:44 ` Ritesh Harjani
2020-05-19 2:43 ` Murphy Zhou
2020-05-21 6:08 ` Ritesh Harjani
2020-05-22 4:56 ` Murphy Zhou
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=20200423112014.GL3737@quack2.suse.cz \
--to=jack@suse.cz \
--cc=adilger@dilger.ca \
--cc=amir73il@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.carpenter@oracle.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=jencce.kernel@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=riteshh@linux.ibm.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.