Re: [PATCH 08/20] ext4: Remove direct usage of fiemap_extent_info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Oct 30, 2018, at 7:18 AM, Carlos Maiolino <cmaiolino@xxxxxxxxxx> wrote:
> 
> struct fiemap_extent_info will be gone in later patches, remove its direct usage
> from Ext4.
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
> ---
> fs/ext4/ext4.h    |  2 +-
> fs/ext4/extents.c | 19 ++++++++++---------
> fs/ext4/inline.c  |  7 ++++---
> 3 files changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index acc1ea0e9f40..c7ad6db930f5 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -3023,7 +3023,7 @@ extern struct buffer_head *ext4_get_first_inline_block(struct inode *inode,
> 					struct ext4_dir_entry_2 **parent_de,
> 					int *retval);
> extern int ext4_inline_data_fiemap(struct inode *inode,
> -				   struct fiemap_extent_info *fieinfo,
> +				   struct fiemap_ctx *f_ctx,
> 				   int *has_inline, __u64 start, __u64 len);
> 
> struct iomap;
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index d52aafc34e25..11ee46aff677 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -2151,7 +2151,7 @@ int ext4_ext_insert_extent(handle_t *handle, struct inode *inode,
> 
> static int ext4_fill_fiemap_extents(struct inode *inode,
> 				    ext4_lblk_t block, ext4_lblk_t num,
> -				    struct fiemap_extent_info *fieinfo)
> +				    struct fiemap_ctx *f_ctx)
> {
> 	struct ext4_ext_path *path = NULL;
> 	struct ext4_extent *ex;
> @@ -2277,7 +2277,8 @@ static int ext4_fill_fiemap_extents(struct inode *inode,
> 		}
> 
> 		if (exists) {
> -			err = fiemap_fill_next_extent(fieinfo,
> +			err = fiemap_fill_next_extent(
> +				(struct fiemap_extent_info *)f_ctx->fc_data,

No need to cast void pointer.  This also makes me wonder why you didn't name
fc_data as fc_extent_info instead of making it a void pointer?  I didn't see
any users where it isn't a pointer to struct fiemap_extent_info?

The same is true of all the other filesystem-specific patches - there is no
need to cast from a void *.  Is there a later user where this is used as a
generic data pointer, or is it always going to be a fiemap_extent_info, and
later a fiemap_ctx structure?

> @@ -5040,14 +5041,14 @@ static int ext4_xattr_fiemap(struct inode *inode,
> 	}
> 
> 	if (physical)
> -		error = fiemap_fill_next_extent(fieinfo, 0, physical,
> -						length, flags);
> +		error = fiemap_fill_next_extent(
> +			(struct fiemap_extent_info *)f_ctx->fc_data,

Same...

> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
> index 9c4bac18cc6c..7b9b0da60d54 100644
> --- a/fs/ext4/inline.c
> +++ b/fs/ext4/inline.c
> @@ -1888,8 +1888,9 @@ int ext4_inline_data_fiemap(struct inode *inode,
> 	physical += offsetof(struct ext4_inode, i_block);
> 
> 	if (physical)
> -		error = fiemap_fill_next_extent(fieinfo, start, physical,
> -						inline_len, flags);
> +		error = fiemap_fill_next_extent(
> +			(struct fiemap_extent_info *)f_ctx->fc_data,

Same...


Cheers, Andreas





Attachment: signature.asc
Description: Message signed with OpenPGP


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux