Re: [PATCH v5 0/7] iomap: zero range folio batch support

[Christian Brauner <brauner@kernel.org>]

On Mon, Oct 20, 2025 at 05:14:07PM -0700, Joanne Koong wrote:
> On Tue, Oct 7, 2025 at 4:12 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Fri, 03 Oct 2025 09:46:34 -0400, Brian Foster wrote:
> > > Only minor changes in v5 to the XFS errortag patch. I've kept the R-b
> > > tags because the fundamental logic is the same, but the errortag
> > > mechanism has been reworked and so that one needed a rebase (which turns
> > > out much simpler). A second look certainly couldn't hurt, but otherwise
> > > the associated fstest still works as expected.
> > >
> > > Note that the force zeroing fstests test has since been merged as
> > > xfs/131. Otherwise I still have some followup patches to this work re:
> > > the ext4 on iomap work, but it would be nice to move this along before
> > > getting too far ahead with that.
> > >
> > > [...]
> >
> > Applied to the vfs-6.19.iomap branch of the vfs/vfs.git tree.
> > Patches in the vfs-6.19.iomap branch should appear in linux-next soon.
> >
> > Please report any outstanding bugs that were missed during review in a
> > new review to the original patch series allowing us to drop it.
> >
> > It's encouraged to provide Acked-bys and Reviewed-bys even though the
> > patch has now been applied. If possible patch trailers will be updated.
> >
> > Note that commit hashes shown below are subject to change due to rebase,
> > trailer updates or similar. If in doubt, please check the listed branch.
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
> > branch: vfs-6.19.iomap
> >
> > [1/7] filemap: add helper to look up dirty folios in a range
> >       https://git.kernel.org/vfs/vfs/c/757f5ca76903
> > [2/7] iomap: remove pos+len BUG_ON() to after folio lookup
> >       https://git.kernel.org/vfs/vfs/c/e027b6ecb710
> > [3/7] iomap: optional zero range dirty folio processing
> >       https://git.kernel.org/vfs/vfs/c/5a9a21cb7706
> 
> Hi Christian,
> 
> Thanks for all your work with managing the vfs iomap branch. I noticed
> for vfs-6.19.iomap, this series was merged after a prior patch in the
> branch that had changed the iomap_iter_advance() interface [1]. As
> such for the merging ordering, I think this 3rd patch needs this minor
> patch-up to be compatible with the change made in [1], if you're able
> to fold this in:
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 72196e5021b1..36ee3290669a 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -867,7 +867,8 @@ static int iomap_write_begin(struct iomap_iter *iter,
>         if (folio_pos(folio) > iter->pos) {
>                 len = min_t(u64, folio_pos(folio) - iter->pos,
>                                  iomap_length(iter));
> -               status = iomap_iter_advance(iter, &len);
> +               status = iomap_iter_advance(iter, len);
> +               len = iomap_length(iter);
>                 if (status || !len)
>                         goto out_unlock;

Thank you! Folded as requested!