All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Eric Sandeen <sandeen@redhat.com>, Christoph Hellwig <hch@lst.de>,
	Dave Chinner <david@fromorbit.com>,
	darrick.wong@oracle.com
Subject: Re: [PATCH 08/20] ext4: Remove direct usage of fiemap_extent_info
Date: Tue, 6 Nov 2018 09:49:03 +0100	[thread overview]
Message-ID: <20181106084903.coowb2a3uwox4gvg@odin.usersys.redhat.com> (raw)
In-Reply-To: <A0A39A07-DF3D-4622-AEF3-0434BE89BB73@dilger.ca>

> > 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?

On later patches, the void pointer is used to point to a userspace address or to
a kernel address, depending on the context. (userspace if FIEMAP, kernelspace if
FIBMAP).

> 
> 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?

I believe I made the mistake to not quote the previous thread which led to this
patch, so, quoting it now:

https://www.spinics.net/lists/linux-fsdevel/msg131786.html

More specifically, I think the detailed information about the approach, was
discussed in the 2nd patch of the above RFC series:

https://www.spinics.net/lists/linux-fsdevel/msg131788.html


> 
> > @@ -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...
> 

About the casts, I didn't remember if GCC allowed implicit casting when passing
it into functions (I remember variable assignment implicit cast though), so,
better safe than sorry, but I can remove it without problems in follow-up
patches.

Thanks

> > 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
> 
> 
> 
> 
> 



-- 
Carlos

  reply	other threads:[~2018-11-06 18:13 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30 13:18 [PATCH 00/20] New ->fiemap infrastructure and ->bmap removal Carlos Maiolino
2018-10-30 13:18 ` [PATCH 01/20] fs: Enable bmap() function to properly return errors Carlos Maiolino
2018-10-30 13:18 ` [PATCH 02/20] cachefiles: drop direct usage of ->bmap method Carlos Maiolino
2018-10-30 13:18 ` [PATCH 03/20] ecryptfs: drop direct calls to ->bmap Carlos Maiolino
2018-11-16 15:40   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 04/20] iomap: Rename fiemap_ctx to fiemap_iomap_ctx Carlos Maiolino
2018-11-16 15:44   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 05/20] fs: Introduce fiemap_ctx data structure Carlos Maiolino
2018-11-16 15:46   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 06/20] iomap: Update iomap_fiemap to use new fiemap_ctx structure Carlos Maiolino
2018-11-16 15:48   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 07/20] fiemap: Move fiemap flags to fiemap_ctx Carlos Maiolino
2018-11-05 22:12   ` Andreas Dilger
2018-11-06  8:37     ` Carlos Maiolino
2018-11-16 15:50       ` Christoph Hellwig
2018-11-16 15:51   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 08/20] ext4: Remove direct usage of fiemap_extent_info Carlos Maiolino
2018-11-05 22:13   ` Andreas Dilger
2018-11-06  8:49     ` Carlos Maiolino [this message]
2018-10-30 13:18 ` [PATCH 09/20] f2fs: " Carlos Maiolino
2018-10-31  6:10   ` Chao Yu
2018-10-30 13:18 ` [PATCH 10/20] Btrfs: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 11/20] nilfs2: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 12/20] ocfs2: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 13/20] iomap: " Carlos Maiolino
2018-10-30 13:18 ` [PATCH 14/20] fiemap: Use fiemap_ctx as fiemap_fill_next_extent argument Carlos Maiolino
2018-11-16 15:54   ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 15/20] fiemap: Start using new callback from fiemap_ctx Carlos Maiolino
2018-11-05 22:14   ` Andreas Dilger
2018-11-06  8:52     ` Carlos Maiolino
2018-11-16 15:55       ` Christoph Hellwig
2018-11-19 12:26         ` Carlos Maiolino
2018-11-16 15:57   ` Christoph Hellwig
2018-11-19 12:37     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 16/20] fibmap: Use bmap instead of ->bmap method in ioctl_fibmap Carlos Maiolino
2018-11-16 15:58   ` Christoph Hellwig
2018-11-19 12:41     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 17/20] fiemap: Get rid of fiemap_extent_info Carlos Maiolino
2018-11-05 22:14   ` Andreas Dilger
2018-11-06  8:56     ` Carlos Maiolino
2018-11-16 16:04   ` Christoph Hellwig
2018-11-19 12:47     ` Carlos Maiolino
2018-10-30 13:18 ` [PATCH 18/20] Use FIEMAP for FIBMAP calls Carlos Maiolino
2018-11-05 22:15   ` Andreas Dilger
2018-11-06  9:11     ` Carlos Maiolino
2018-11-16 16:06   ` Christoph Hellwig
2018-11-19 12:50     ` Carlos Maiolino
2018-11-20  8:53       ` Christoph Hellwig
2018-10-30 13:18 ` [PATCH 19/20] xfs: Get rid of ->bmap Carlos Maiolino
2018-10-30 13:18 ` [PATCH 20/20] ext4: Get rid of ->bmap interface Carlos Maiolino
2018-11-16 16:07   ` Christoph Hellwig

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=20181106084903.coowb2a3uwox4gvg@odin.usersys.redhat.com \
    --to=cmaiolino@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.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 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.