From: "Darrick J. Wong" <djwong@kernel.org>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
Joanne Koong <joannelkoong@gmail.com>,
Brian Foster <bfoster@redhat.com>,
Damien Le Moal <dlemoal@kernel.org>,
Hannes Reinecke <hare@suse.de>,
Daniel Gomez <da.gomez@samsung.com>,
Pankaj Raghav <p.raghav@samsung.com>,
Dave Chinner <dchinner@redhat.com>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/3] iomap: don't lose a fiemap iteration error when emitting the last extent
Date: Mon, 21 Sep 2026 15:31:55 -0700 [thread overview]
Message-ID: <20260921223155.GN6283@frogsfrogsfrogs> (raw)
In-Reply-To: <20260921083133.2960-3-parri.andrea@gmail.com>
On Mon, Sep 21, 2026 at 10:31:32AM +0200, Andrea Parri wrote:
> iomap_fiemap() emits extents one behind: iomap_fiemap_iter() flushes the
> previous extent and remembers the current one, and the remembered extent
> is written with FIEMAP_EXTENT_LAST after the iteration loop.
>
> That final flush overwrites ret, so when ->iomap_begin() fails partway
> through the iteration the error is replaced by the result of
> iomap_to_fiemap() (zero on success) and iomap_fiemap() returns success
> with a truncated extent list whose last entry is wrongly marked as the
> last extent in the file. The pre-iomap_iter code returned the error
> from inside the loop, before flushing the pending extent.
>
> Check for the iteration error before flushing the pending extent, so
> that real errors are propagated and only a successful iteration emits
> the final FIEMAP_EXTENT_LAST extent. -ENOENT (no mapping) is still not
> an error, and the pending extent is still emitted in that case.
>
> Fixes: 7892386d35715 ("iomap: switch iomap_fiemap to use iomap_iter")
> Cc: stable@vger.kernel.org
Oooh, an oldie!
Cc: <stable@vger.kernel.org> # v5.15
> Assisted-by: LLM
> Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> fs/iomap/fiemap.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/iomap/fiemap.c b/fs/iomap/fiemap.c
> index d11dadff82865..54b824b7edb5c 100644
> --- a/fs/iomap/fiemap.c
> +++ b/fs/iomap/fiemap.c
> @@ -76,15 +76,15 @@ int iomap_fiemap(struct inode *inode, struct fiemap_extent_info *fi,
> while ((ret = iomap_iter(&iter, ops)) > 0)
> iter.status = iomap_fiemap_iter(&iter, fi, &prev);
>
> + /* inode with no (attribute) mapping will give ENOENT */
> + if (ret < 0 && ret != -ENOENT)
> + return ret;
> +
> if (prev.type != IOMAP_HOLE) {
> ret = iomap_to_fiemap(fi, &prev, FIEMAP_EXTENT_LAST);
> if (ret < 0)
> return ret;
> }
> -
> - /* inode with no (attribute) mapping will give ENOENT */
> - if (ret < 0 && ret != -ENOENT)
> - return ret;
> return 0;
> }
> EXPORT_SYMBOL_GPL(iomap_fiemap);
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-09-21 22:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 8:31 [PATCH 0/3] iomap: fix error handling regressions Andrea Parri
2026-09-21 8:31 ` [PATCH 1/3] iomap: don't resubmit an ioend after ->writeback_submit() failed Andrea Parri
2026-09-21 22:29 ` Darrick J. Wong
2026-09-22 5:34 ` Christoph Hellwig
2026-09-22 8:53 ` Andrea Parri
2026-09-22 5:33 ` Christoph Hellwig
2026-09-22 9:03 ` Andrea Parri
2026-09-22 12:29 ` Christoph Hellwig
2026-09-22 19:00 ` Andrea Parri
2026-09-21 8:31 ` [PATCH 2/3] iomap: don't lose a fiemap iteration error when emitting the last extent Andrea Parri
2026-09-21 22:31 ` Darrick J. Wong [this message]
2026-09-22 5:34 ` Christoph Hellwig
2026-09-21 8:31 ` [PATCH 3/3] iomap: don't lose a failed direct I/O bio's error when zeroing the tail Andrea Parri
2026-09-21 22:34 ` Darrick J. Wong
2026-09-22 5:36 ` Christoph Hellwig
2026-09-22 9:10 ` Andrea Parri
2026-09-22 12:28 ` Christoph Hellwig
2026-09-22 18:43 ` Andrea Parri
2026-09-21 18:07 ` [PATCH 0/3] iomap: fix error handling regressions Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260921223155.GN6283@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dchinner@redhat.com \
--cc=dlemoal@kernel.org \
--cc=hare@suse.de \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=p.raghav@samsung.com \
--cc=parri.andrea@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.