On Tue, Jun 23, 2026 at 6:52 AM Christoph Hellwig <[email protected]> wrote:
>
> Currently the iomap buffered read path tries to build up read context
> (i.e. bios for the typical block based case) over multiple iomaps as
> long as the sector matches. This does not take into account files
> that can map to multiple different devices. While this could be fixed
> by a bdev check in iomap_bio_read_folio_range, the building up of I/O
> over iomaps actually was a problem for the not yet merged ext2 iomap
> port, as that does want to send out I/O at the end of an indirect
> block mapped range.
>
> So instead of adding more checks move over to a model where a bio only
> spans a single iomap. Change ->submit_read to be called after each
> iteration, and pass a force argument to indicate that the bio must
> be submitted set on the last iteration. Switch the bio based users
> to always submit, while keeping the single submit for fuse.
>
> Fixes: dfeab2e95a75 ("erofs: add multiple device support")
> Reported-by: Kelu Ye <[email protected]>
> Reported-by: Yifan Zhao <[email protected]>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> fs/exfat/iomap.c | 4 ++--
> fs/fuse/file.c | 6 +++++-
> fs/iomap/bio.c | 11 +++++++----
> fs/iomap/buffered-io.c | 23 +++++++++++++++--------
> fs/ntfs/aops.c | 4 ++--
> fs/ntfs3/inode.c | 4 ++--
> fs/xfs/xfs_aops.c | 5 +++--
> include/linux/iomap.h | 5 +++--
> 8 files changed, 39 insertions(+), 23 deletions(-)
>
> diff --git a/fs/iomap/bio.c b/fs/iomap/bio.c
> index 0f31e35567b4..f71aaaf60301 100644
> --- a/fs/iomap/bio.c
> +++ b/fs/iomap/bio.c
> @@ -79,7 +79,8 @@ u32 iomap_finish_ioend_buffered_read(struct iomap_ioend
> *ioend)
> }
>
> 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
> + bio_end_io_t end_io)
> {
> struct bio *bio = ctx->read_ctx;
>
> @@ -87,13 +88,15 @@ void iomap_bio_submit_read_endio(const struct iomap_iter
> *iter,
> if (iter->iomap.flags & IOMAP_F_INTEGRITY)
> fs_bio_integrity_alloc(bio);
> submit_bio(bio);
> +
> + ctx->read_ctx = NULL;
> }
> EXPORT_SYMBOL_GPL(iomap_bio_submit_read_endio);
>
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 8d4806dc46d4..06a216d37548 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
>
> @@ -642,12 +649,12 @@ void iomap_read_folio(const struct iomap_ops *ops,
> fsverity_readahead(ctx->vi, folio->index,
> folio_nr_pages(folio));
>
> - 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?
Thanks,
Joanne
