nvdimm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	Shiyang Ruan <ruansy.fnst@fujitsu.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-btrfs@vger.kernel.org, nvdimm@lists.linux.dev,
	cluster-devel@redhat.com
Subject: Re: [PATCH 16/27] iomap: switch iomap_bmap to use iomap_iter
Date: Mon, 26 Jul 2021 09:39:22 -0700	[thread overview]
Message-ID: <20210726163922.GA559142@magnolia> (raw)
In-Reply-To: <20210726081942.GD14853@lst.de>

On Mon, Jul 26, 2021 at 10:19:42AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 19, 2021 at 10:05:45AM -0700, Darrick J. Wong wrote:
> > >  	bno = 0;
> > > -	ret = iomap_apply(inode, pos, blocksize, 0, ops, &bno,
> > > -			  iomap_bmap_actor);
> > > +	while ((ret = iomap_iter(&iter, ops)) > 0) {
> > > +		if (iter.iomap.type != IOMAP_MAPPED)
> > > +			continue;
> > 
> > There isn't a mapped extent, so return 0 here, right?
> 
> We can't just return 0, we always need the final iomap_iter() call
> to clean up in case a ->iomap_end method is supplied.  No for bmap
> having and needing one is rather theoretical, but people will copy
> and paste that once we start breaking the rules.

Oh, right, I forgot that someone might want to ->iomap_end.  The
"continue" works because we only asked for one block, therefore we know
that we'll never get to the loop body a second time; and we ignore
iter.processed, which also means we never revisit the loop body.

This "continue without setting iter.processed to break out of loop"
pattern is a rather indirect subtlety, since C programmers are taught
that they can break out of a loop using break;.  This new iomap_iter
pattern fubars that longstanding language feature, and the language
around it is soft:

> /**
>  * iomap_iter - iterate over a ranges in a file
>  * @iter: iteration structue
>  * @ops: iomap ops provided by the file system
>  *
>  * Iterate over file system provided contiguous ranges of blocks with the same
>  * state.  Should be called in a loop that continues as long as this function
>  * returns a positive value.  If 0 or a negative value is returned the caller
>  * should break out of the loop - a negative value is an error either from the
>  * file system or from the last iteration stored in @iter.copied.
>  */

The documentation needs to be much more explicit about the fact that you
cannot "break;" your way out of an iomap_iter loop.  I think the comment
should be rewritten along these lines:

"Iterate over filesystem-provided space mappings for the provided file
range.  This function handles cleanup of resources acquired for
iteration when the filesystem indicates there are no more space
mappings, which means that this function must be called in a loop that
continues as long it returns a positive value.  If 0 or a negative value
is returned, the caller must not return to the loop body.  Within a loop
body, there are two ways to break out of the loop body: leave
@iter.processed unchanged, or set it to the usual negative errno."

Hm.

What if we provide an explicit loop break function?  That would be clear
overkill for bmap, but somebody else wanting to break out of a more
complex loop body ought to be able to say "break" to do that, not
"continue with subtleties".

static inline int
iomap_iter_break(struct iomap_iter *iter, int ret)
{
	int ret2;

	if (!iter->iomap.length || !ops->iomap_end)
		return ret;

	ret2 = ops->iomap_end(iter->inode, iter->pos, iomap_length(iter),
			0, iter->flags, &iter->iomap);
	return ret ? ret : ret2;
}

And then then theoretical loop body becomes:

	while ((ret = iomap_iter(&iter, ops)) > 0) {
		if (iter.iomap.type != WHAT_I_WANT) {
			ret = iomap_iter_break(&iter, 0);
			break;
		}

		<large blob of code here>

		ret = vfs_do_some_risky_thing(...);
		if (ret) {
			ret = iomap_iter_break(&iter, ret);
			break;
		}

		<more loop body here>

		iter.processed = iter.iomap.length;
	}
	return ret;

Clunky, for sure, but at least we still get to use break as the language
designers intended.

--D

  reply	other threads:[~2021-07-26 16:39 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 10:34 RFC: switch iomap to an iterator model Christoph Hellwig
2021-07-19 10:34 ` [PATCH 01/27] iomap: fix a trivial comment typo in trace.h Christoph Hellwig
2021-07-19 16:00   ` Darrick J. Wong
2021-07-19 10:34 ` [PATCH 02/27] iomap: remove the iomap arguments to ->page_{prepare,done} Christoph Hellwig
2021-07-19 16:04   ` Darrick J. Wong
2021-07-19 10:34 ` [PATCH 03/27] iomap: mark the iomap argument to iomap_sector const Christoph Hellwig
2021-07-19 16:08   ` Darrick J. Wong
2021-07-20  9:52     ` Nikolay Borisov
2021-07-26  8:12     ` Christoph Hellwig
2021-07-19 10:34 ` [PATCH 04/27] fs: mark the iomap argument to __block_write_begin_int const Christoph Hellwig
2021-07-19 17:35   ` Darrick J. Wong
2021-07-19 10:34 ` [PATCH 05/27] fsdax: mark the iomap argument to dax_iomap_sector as const Christoph Hellwig
2021-07-19 17:35   ` Darrick J. Wong
2021-07-19 10:34 ` [PATCH 06/27] iomap: mark the iomap argument to iomap_read_inline_data const Christoph Hellwig
2021-07-19 17:35   ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 07/27] iomap: mark the iomap argument to iomap_read_page_sync const Christoph Hellwig
2021-07-19 17:35   ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 08/27] iomap: add the new iomap_iter model Christoph Hellwig
2021-07-19 16:56   ` Darrick J. Wong
2021-07-26  8:15     ` Christoph Hellwig
2021-07-19 21:48   ` Dave Chinner
2021-07-26  8:17     ` Christoph Hellwig
2021-07-19 10:35 ` [PATCH 09/27] iomap: switch readahead and readpage to use iomap_iter Christoph Hellwig
2021-07-19 10:35 ` [PATCH 10/27] iomap: switch iomap_file_buffered_write " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 11/27] iomap: switch iomap_file_unshare " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 12/27] iomap: switch iomap_zero_range " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 13/27] iomap: switch iomap_page_mkwrite " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 14/27] iomap: switch __iomap_dio_rw " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 15/27] iomap: switch iomap_fiemap " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 16/27] iomap: switch iomap_bmap " Christoph Hellwig
2021-07-19 17:05   ` Darrick J. Wong
2021-07-26  8:19     ` Christoph Hellwig
2021-07-26 16:39       ` Darrick J. Wong [this message]
2021-07-27  6:31         ` Christoph Hellwig
2021-07-27 14:32           ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 17/27] iomap: switch iomap_seek_hole " Christoph Hellwig
2021-07-19 17:22   ` Darrick J. Wong
2021-07-26  8:22     ` Christoph Hellwig
2021-07-26 16:41       ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 18/27] iomap: switch iomap_seek_data " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 19/27] iomap: switch iomap_swapfile_activate " Christoph Hellwig
2021-07-19 10:35 ` [PATCH 20/27] fsdax: switch dax_iomap_rw " Christoph Hellwig
2021-07-19 22:10   ` Dave Chinner
2021-07-26  8:25     ` Christoph Hellwig
2021-07-19 10:35 ` [PATCH 21/27] iomap: remove iomap_apply Christoph Hellwig
2021-07-19 17:48   ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 22/27] iomap: pass an iomap_iter to various buffered I/O helpers Christoph Hellwig
2021-07-19 17:48   ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 23/27] iomap: rework unshare flag Christoph Hellwig
2021-07-19 17:44   ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 24/27] fsdax: factor out helpers to simplify the dax fault code Christoph Hellwig
2021-07-19 10:35 ` [PATCH 25/27] fsdax: factor out a dax_fault_actor() helper Christoph Hellwig
2021-07-19 10:35 ` [PATCH 26/27] fsdax: switch the fault handlers to use iomap_iter Christoph Hellwig
2021-07-19 17:35   ` Darrick J. Wong
2021-07-19 10:35 ` [PATCH 27/27] iomap: constify iomap_iter_srcmap Christoph Hellwig
2021-07-19 17:44   ` Darrick J. Wong
2021-07-19 17:57 ` RFC: switch iomap to an iterator model Darrick J. Wong
2021-07-27  8:07   ` DAX setup pains, was " Christoph Hellwig
2021-07-29 20:33 ` Darrick J. Wong

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=20210726163922.GA559142@magnolia \
    --to=djwong@kernel.org \
    --cc=agruenba@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=ruansy.fnst@fujitsu.com \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH 16/27] iomap: switch iomap_bmap to use iomap_iter' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox