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

[Brian Foster <bfoster@redhat.com>]

On Fri, Jan 31, 2025 at 12:08:03AM -0800, Christoph Hellwig wrote:
> 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?
> 
> 

No problem. I originally had this split up, then combined some of it
because the changes seemed trivial, then I think it became a little too
convoluted again. I think I should be able to split this back up into
two or three incremental patches..

Brian