Re: [PATCH v3 3/7] iomap: refactor iter and advance continuation logic

[Christoph Hellwig <hch@infradead.org>]

On Thu, Jan 30, 2025 at 12:09:44PM -0500, Brian Foster wrote:
> In preparation for future changes and more generic use of
> iomap_iter_advance(), lift the high level iter continuation logic
> out of iomap_iter_advance() into the caller. Also add some comments
> and rework iomap_iter() to jump straight to ->iomap_begin() on the
> first iteration.

It took me a bit to reoncile the commit log with the changes.

What this does is:

 1) factor out a iomap_iter_reset_iomap caller from iomap_iter_advance
 2) pass an explicit count to iomap_iter_advance instead of derіving
    it from iter->processed inside of iomap_iter_advance
 3) only call iomap_iter_advance condititional on iter->iomap.length,
    and thus skipping the code that is now in iomap_iter_reset_iomap
    when iter->iomap.length is 0.

All this looks fine, although I wonder why we didn't do 3) before and
if there is a risk of a regression for some weird corner case.

I hate nitpicking too much, but maybe split the three steps into
separate patches so that 3) is clearly documented and can be bisected
if problems arise?