linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] iomap: Add iomap_iter
Date: Tue, 11 Aug 2020 14:01:27 -0700	[thread overview]
Message-ID: <20200811210127.GG6107@magnolia> (raw)
In-Reply-To: <20200728173216.7184-2-willy@infradead.org>

On Tue, Jul 28, 2020 at 06:32:14PM +0100, Matthew Wilcox (Oracle) wrote:
> The iomap_iter provides a convenient way to package up and maintain
> all the arguments to the various mapping and operation functions.
> iomi_advance() moves the iterator forward to the next chunk of the file.
> This approach has only one callback to the filesystem -- the iomap_next_t
> instead of the separate iomap_begin / iomap_end calls.  This slightly
> complicates the filesystems, but is more efficient.  The next function

How much more efficient?  I've wondered since the start of
spectre/meltdown if in ten years we're still going to appreciate the
increase in code complexity that comes from trying to avoid indirect
function calls.  That said, we needed an iomap iterator long before
that, so I think I mostly like this.

> will be called even after an error has occurred to allow the filesystem
> the opportunity to clean up.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
>  fs/iomap/apply.c      | 29 ++++++++++++++++++++++
>  include/linux/iomap.h | 57 +++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+)
> 
> diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c
> index 76925b40b5fd..c83dcd203558 100644
> --- a/fs/iomap/apply.c
> +++ b/fs/iomap/apply.c
> @@ -92,3 +92,32 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags,
>  
>  	return written ? written : ret;
>  }
> +
> +bool iomi_advance(struct iomap_iter *iomi, int err)
> +{
> +	struct iomap *iomap = &iomi->iomap;
> +
> +	if (likely(!err)) {
> +		iomi->pos += iomi->copied;
> +		iomi->len -= iomi->copied;
> +		iomi->ret += iomi->copied;
> +		if (!iomi->len)
> +			return false;
> +		iomi->copied = 0;
> +		if (WARN_ON(iomap->offset > iomi->pos))
> +			err = -EIO;
> +		if (WARN_ON(iomap->offset + iomap->length <= iomi->pos))
> +			err = -EIO;
> +	}
> +
> +	if (unlikely(err < 0)) {
> +		if (iomi->copied < 0)
> +			return false;
> +		/* Give the body a chance to see the error and clean up */
> +		iomi->copied = err;
> +		if (!iomi->ret)
> +			iomi->ret = err;
> +	}
> +	return true;
> +}
> +EXPORT_SYMBOL_GPL(iomi_advance);
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index 4d1d3c3469e9..fe58e68ec0c1 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -142,6 +142,63 @@ struct iomap_ops {
>  			ssize_t written, unsigned flags, struct iomap *iomap);
>  };
>  
> +/**
> + * struct iomap_iter - Iterate through a range of a file.
> + * @inode: Set at the start of the iteration and should not change.
> + * @pos: The current file position we are operating on.  It is updated by
> + *	calls to iomap_iter().  Treat as read-only in the body.
> + * @len: The remaining length of the file segment we're operating on.
> + *	It is updated at the same time as @pos.
> + * @ret: What we want our declaring function to return.  It is initialised
> + *	to zero and is the cumulative number of bytes processed so far.
> + *	It is updated at the same time as @pos.
> + * @copied: The number of bytes operated on by the body in the most
> + *	recent iteration.  If no bytes were operated on, it may be set to
> + *	a negative errno.  0 is treated as -EIO.
> + * @flags: Zero or more of the iomap_begin flags above.
> + * @iomap: ...
> + * @srcma:s ...

...? :)

> + */
> +struct iomap_iter {
> +	struct inode *inode;
> +	loff_t pos;
> +	u64 len;

Thanks for leaving this u64 :)

> +	loff_t ret;
> +	ssize_t copied;

Is this going to be sufficient for SEEK_{HOLE,DATA} when it wants to
jump ahead by more than 2GB?

> +	unsigned flags;
> +	struct iomap iomap;
> +	struct iomap srcmap;
> +};
> +
> +#define IOMAP_ITER(name, _inode, _pos, _len, _flags)			\
> +	struct iomap_iter name = {					\
> +		.inode = _inode,					\
> +		.pos = _pos,						\
> +		.len = _len,						\
> +		.flags = _flags,					\
> +	}
> +
> +typedef int (*iomap_next_t)(const struct iomap_iter *,
> +		struct iomap *iomap, struct iomap *srcmap);

I muttered in my other reply how these probably should be called
iomap_iter_advance_t since they actually do the upper level work of
advancing the iterator to the next mapping.

--D

> +bool iomi_advance(struct iomap_iter *iomi, int err);
> +
> +static inline bool iomap_iter(struct iomap_iter *iomi, iomap_next_t next)
> +{
> +	if (iomi->ret && iomi->copied == 0)
> +		iomi->copied = -EIO;
> +
> +	return iomi_advance(iomi, next(iomi, &iomi->iomap, &iomi->srcmap));
> +}
> +
> +static inline u64 iomap_length(const struct iomap_iter *iomi)
> +{
> +	u64 end = iomi->iomap.offset + iomi->iomap.length;
> +
> +	if (iomi->srcmap.type != IOMAP_HOLE)
> +		end = min(end, iomi->srcmap.offset + iomi->srcmap.length);
> +	return min(iomi->len, end - iomi->pos);
> +}
> +
>  /*
>   * Main iomap iterator function.
>   */
> -- 
> 2.27.0
> 

  reply	other threads:[~2020-08-11 21:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 17:32 [RFC 0/2] Avoid indirect function calls in iomap Matthew Wilcox (Oracle)
2020-07-28 17:32 ` [PATCH 1/2] iomap: Add iomap_iter Matthew Wilcox (Oracle)
2020-08-11 21:01   ` Darrick J. Wong [this message]
2020-08-11 21:32     ` Matthew Wilcox
2020-07-28 17:32 ` [PATCH 2/2] iomap: Convert readahead to iomap_iter Matthew Wilcox (Oracle)
2020-08-11 20:56   ` Darrick J. Wong
2020-08-11 22:31     ` Matthew Wilcox

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=20200811210127.GG6107@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=willy@infradead.org \
    /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).