On Tue, Jun 23, 2026 at 10:29:54AM -0700, Joanne Koong wrote:
> > void iomap_bio_submit_read_endio(const struct iomap_iter *iter,
> > - struct iomap_read_folio_ctx *ctx, bio_end_io_t end_io)
> > + struct iomap_read_folio_ctx *ctx, bool force,
>
> nit: might simplify things to drop the unused force arg
I guess this is not directly used as a method, so we could.
> >
> > - while ((ret = iomap_iter(&iter, ops)) > 0)
> > + while ((ret = iomap_iter(&iter, ops)) > 0) {
> > + iomap_submit_read(&iter, ctx, false);
> > iter.status = iomap_read_folio_iter(&iter, ctx,
> > &bytes_submitted);
>
> should the submit_read happen after the iomap_read_folio_iter() /
> iomap_readahead_iter() instaed of before? From what I see, it looks
> like iomap_submit_read() would hold the iter state of the next
> mapping. It seems like in iomap_bio_submit_read_endio(), the
> iter->iomap.flags would be the next extent's flags instead of the one
> that needs to be submitted?
Yeah, the iter state would be wrong here if anyone actually used it.
But the only thing we actually ever use from it is the inode in XFS.
So I'm tempted to instead just adopt the signature to not pass the
iter, as nothing should rely on it. The only interesting thing I could
think of for the future would be to pass on private data, but that's
probably better left for when we actually need it.
