From: Christian Brauner <brauner@kernel.org>
Date: Thu, 30 Jul 2026 10:32:33 +0000 (+0200)
Subject: Merge patch series "iomap: convert to in-iter iomap_next() model"
X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=9abed87b07aba5c21bcc5b49c39ca3325df29192;p=thirdparty%2Flinux.git

Merge patch series "iomap: convert to in-iter iomap_next() model"

Joanne Koong <joannelkoong@gmail.com> says:

iomap: convert to in-iter iomap_next() model

This series implements a suggestion by Christoph for finishing the conversion
of iomap to an iterator model. This revives Matthew's previous RFC [1], which
had the same intention.

Every iomap operation currently drives its iteration through a struct
iomap_ops, which contains two callbacks, ->iomap_begin() and ->iomap_end().
iomap_iter() only ever sees these as pointers, so every step of every
iteration is an indirect call, including on the hottest paths.

This series replaces the begin/end pair with a single ->iomap_next() callback
that finishes the previous mapping (if any) and produces the next one.
Collapsing to one callback lets a performance-critical caller inline its
iteration loop and pass its ->iomap_next() function as a compile-time
constant, where the compiler can devirtualize the callback into a direct and
inlineable call rather than an indirect one. It also allows future callers
more flexibility in expressing custom logic in the IO path for driving the
iteration forward.

This series has no functional changes intended. The patches are broken down as
follows:

1) Patch 1: Brian's fix for folio batch release on iomap callback failures.
   The bug was reported by Sashiko and is an unlikely/second order error
   scenario [2] that doesn't need backporting to stable.

2) Patch 2: refactors existing iomap_iter() logic into an iomap_iter_next()
   function. Sets up DEFINE_IOMAP_ITER_NEXT/DEFINE_IOMAP_ITER_NEXT_END macro.

3) Patch 3 and 4: Christoph's patches for decoupling simple direct i/o reads
   from iomap_dio_rw and improvement for using GFP_NOWAIT for
   non-blocking iocbs [3]

4) Patch 5: Adds ->iomap_next() callback as an iomap op

5) Patches 6 to 19: converts each filesystem to ->iomap_next() model

[1] https://lore.kernel.org/linux-fsdevel/20200728173216.7184-1-willy@infradead.org/T/#u
[2] https://lore.kernel.org/linux-fsdevel/amjztG-DisHYbV9W@bfoster/
[3] https://lore.kernel.org/linux-fsdevel/20260723050201.3381045-1-hch@lst.de/

* patches from https://patch.msgid.link/20260729192737.3190206-1-joannelkoong@gmail.com:
  exfat: convert iomap ops to ->iomap_next()
  fuse: convert iomap ops to ->iomap_next()
  hpfs: convert iomap ops to ->iomap_next()
  gfs2: convert iomap ops to ->iomap_next()
  f2fs: convert iomap ops to ->iomap_next()
  block: convert iomap ops to ->iomap_next()
  ext2: convert iomap ops to ->iomap_next()
  zonefs: convert iomap ops to ->iomap_next()
  erofs: convert iomap ops to ->iomap_next()
  ext4: convert iomap ops to ->iomap_next()
  ntfs: convert iomap ops to ->iomap_next()
  ntfs3: convert iomap ops to ->iomap_next()
  btrfs: convert iomap ops to ->iomap_next()
  xfs: convert iomap ops to ->iomap_next()
  iomap: add ->iomap_next()
  iomap: use GFP_NOWAIT when application for iomap_dio_simple allocations
  iomap: decouple simple direct I/O reads from iomap_dio_rw
  iomap: split iomap_iter() logic into iomap_iter_next()
  iomap: release the folio batch on iomap callback failures

Link: https://patch.msgid.link/20260729192737.3190206-1-joannelkoong@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---

9abed87b07aba5c21bcc5b49c39ca3325df29192