mbox series

[00/10] iomap: incremental advance conversion -- phase 2

Message ID 20250212135712.506987-1-bfoster@redhat.com (mailing list archive)
Headers show
Series iomap: incremental advance conversion -- phase 2 | expand

Message

Brian Foster Feb. 12, 2025, 1:57 p.m. UTC
Hi all,

Here's phase 2 of the incremental iter advance conversions. This updates
all remaining iomap operations to advance the iter within the operation
and thus removes the need to advance from the core iomap iterator. Once
all operations are switched over, the core advance code is removed and
the processed field is renamed to reflect that it is now a pure status
code.

For context, this was first introduced in a previous series [1] that
focused mainly on the core mechanism and iomap buffered write. This is
because original impetus was to facilitate a folio batch mechanism where
a filesystem can optionally provide a batch of folios to process for a
given mapping (i.e. zero range of an unwritten mapping with dirty folios
in pagecache). That is still WIP, but the broader point is that this was
originally intended as an optional mode until consensus that fell out of
discussion was that it would be preferable to convert over everything.
This presumably facilitates some other future work and simplifies
semantics in the core iteration code.

Patches 1-3 convert over iomap buffered read, direct I/O and various
other remaining ops (swap, etc.). Patches 4-8 convert over the various
DAX iomap operations. Finally, patches 9-10 remove the old iomap_iter()
advance logic and clean up the name and type of the iter.processed
field, respectively.

Note that I've taken an intentional shortcut here in the DAX read/write
I/O path (patch 4). In principle and for consistency, the advance in
this path should occur one layer down in dax_iomap_iter(). I have
followup patches to do that, but they were not yet working properly. I
think I'm close to having the kinks worked out on that. A bit more
testing is required and I intend to include that as a standalone patch
anyways, so I didn't want to hold up a v1 pass just for that. Otherwise
this survives my testing so far.

Thoughts, reviews, flames appreciated.

Brian

P.S., I'm also coming up on a short holiday so response to feedback may
be delayed.

[1] https://lore.kernel.org/linux-fsdevel/20250207143253.314068-1-bfoster@redhat.com/

Brian Foster (10):
  iomap: advance the iter directly on buffered read
  iomap: advance the iter on direct I/O
  iomap: convert misc simple ops to incremental advance
  dax: advance the iomap_iter in the read/write path
  dax: advance the iomap_iter on zero range
  dax: advance the iomap_iter on unshare range
  dax: advance the iomap_iter on dedupe range
  dax: advance the iomap_iter on pte and pmd faults
  iomap: remove unnecessary advance from iomap_iter()
  iomap: rename iomap_iter processed field to status

 fs/dax.c               | 94 +++++++++++++++++++++++++-----------------
 fs/iomap/buffered-io.c | 78 +++++++++++++++++------------------
 fs/iomap/direct-io.c   | 25 +++++++----
 fs/iomap/fiemap.c      | 22 +++++-----
 fs/iomap/iter.c        | 42 +++++++------------
 fs/iomap/seek.c        | 16 +++----
 fs/iomap/swapfile.c    |  9 ++--
 fs/iomap/trace.h       |  8 ++--
 include/linux/iomap.h  |  7 ++--
 9 files changed, 160 insertions(+), 141 deletions(-)