On Tue, Feb 04, 2025 at 11:23:53AM -0800, Darrick J. Wong wrote:
> On Tue, Feb 04, 2025 at 08:30:38AM -0500, Brian Foster wrote:
> > The error code is only used to check whether iomap_iter() should
> > terminate due to an error returned in iter.processed. Lift the check
> > out of iomap_iter_advance() in preparation to make it more generic.
> >
> > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
> > ---
> > fs/iomap/iter.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
> > index a2ae99fe6431..fcc8d75dd22f 100644
> > --- a/fs/iomap/iter.c
> > +++ b/fs/iomap/iter.c
> > @@ -30,8 +30,6 @@ static inline int iomap_iter_advance(struct iomap_iter *iter, s64 count)
> > bool stale = iter->iomap.flags & IOMAP_F_STALE;
> > int ret = 1;
> >
> > - if (count < 0)
> > - return count;
> > if (WARN_ON_ONCE(count > iomap_length(iter)))
> > return -EIO;
> > iter->pos += count;
> > @@ -86,6 +84,11 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
> > return ret;
> > }
> >
> > + if (iter->processed < 0) {
> > + iomap_iter_reset_iomap(iter);
> > + return iter->processed;
>
> Doesn't iomap_iter_reset_iomap reset iter->processed to zero?
>
Urgh.. factoring breakage. Patches 3-6 were all one patch in v3 and for
some reason I left the processed = iter->processed assignment that
avoids this problem for patch 6. That should probably get pulled back to
here. I'll fix that up in v5.
Brian
> --D
>
> > + }
> > +
> > /* advance and clear state from the previous iteration */
> > ret = iomap_iter_advance(iter, iter->processed);
> > iomap_iter_reset_iomap(iter);
> > --
> > 2.48.1
> >
> >
>
