| Message ID | 20250212135712.506987-3-bfoster@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | iomap: incremental advance conversion -- phase 2 | expand |
On Wed, Feb 12, 2025 at 08:57:04AM -0500, Brian Foster wrote: > Update iomap direct I/O to advance the iter directly rather than via > iter.processed. Since unique subhelpers exist for various mapping > types, advance in the commonly called iomap_dio_iter() function. > Update the switch statement branches to fall out, advance by the > number of bytes processed and return either success or failure. Can we push the advance into iomap_dio_{bio,hole,inline}_iter? It think that would be a bit cleaner as I tried to keep them as self-contained as possible.
On Wed, Feb 12, 2025 at 10:51:52PM -0800, Christoph Hellwig wrote: > On Wed, Feb 12, 2025 at 08:57:04AM -0500, Brian Foster wrote: > > Update iomap direct I/O to advance the iter directly rather than via > > iter.processed. Since unique subhelpers exist for various mapping > > types, advance in the commonly called iomap_dio_iter() function. > > Update the switch statement branches to fall out, advance by the > > number of bytes processed and return either success or failure. > > Can we push the advance into iomap_dio_{bio,hole,inline}_iter? > It think that would be a bit cleaner as I tried to keep them as > self-contained as possible. > > Sure, I think we can do it that way if that's preferable. I'll have to take a closer look at iomap_dio_bio_iter() as that one looks a little more involved at a glance, but TBH I suspect the worst case is we could advance in the out path and have pretty much the same behavior as this patch. Brian
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index b521eb15759e..cb0b0b0f07b3 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -515,22 +515,29 @@ static loff_t iomap_dio_inline_iter(const struct iomap_iter *iomi, return copied; } -static loff_t iomap_dio_iter(const struct iomap_iter *iter, +static int iomap_dio_iter(struct iomap_iter *iter, struct iomap_dio *dio) { + loff_t len; + switch (iter->iomap.type) { case IOMAP_HOLE: if (WARN_ON_ONCE(dio->flags & IOMAP_DIO_WRITE)) return -EIO; - return iomap_dio_hole_iter(iter, dio); + len = iomap_dio_hole_iter(iter, dio); + break; case IOMAP_UNWRITTEN: if (!(dio->flags & IOMAP_DIO_WRITE)) - return iomap_dio_hole_iter(iter, dio); - return iomap_dio_bio_iter(iter, dio); + len = iomap_dio_hole_iter(iter, dio); + else + len = iomap_dio_bio_iter(iter, dio); + break; case IOMAP_MAPPED: - return iomap_dio_bio_iter(iter, dio); + len = iomap_dio_bio_iter(iter, dio); + break; case IOMAP_INLINE: - return iomap_dio_inline_iter(iter, dio); + len = iomap_dio_inline_iter(iter, dio); + break; case IOMAP_DELALLOC: /* * DIO is not serialised against mmap() access at all, and so @@ -545,6 +552,10 @@ static loff_t iomap_dio_iter(const struct iomap_iter *iter, WARN_ON_ONCE(1); return -EIO; } + + if (len < 0) + return len; + return iomap_iter_advance(iter, &len); } /*
Update iomap direct I/O to advance the iter directly rather than via iter.processed. Since unique subhelpers exist for various mapping types, advance in the commonly called iomap_dio_iter() function. Update the switch statement branches to fall out, advance by the number of bytes processed and return either success or failure. Signed-off-by: Brian Foster <bfoster@redhat.com> --- fs/iomap/direct-io.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-)