Re: [PATCH v2] iomap: guard io_size EOF trim against concurrent truncate underflow

Re: [PATCH v2] iomap: guard io_size EOF trim against concurrent truncate underflow

[Morduan Zang]

On Thu, Jun 18, 2026 at 07:03:07PM +0800, Christian Brauner wrote:
> Ok, makes sense.
>
> I don't think it's impossible.  Just curious where this change comes
> from and hoping for a reproducer if we can come up with one.

Thanks for the feedback.

This came from our backport review of 51d20d1dacbe — static analysis
flagged that end_pos - ioend->io_offset is assigned to size_t without
ensuring end_pos >= ioend->io_offset. I do not have a runtime reproducer
yet; I am still trying to set up a test on XFS with bsize < PAGE_SIZE to
see if writeback can reach iomap_add_to_ioend() with end_pos below
io_offset. I will follow up if I get a concrete result.

I will send a v2 with your suggested ordering shortly. 
If I manage toreproduce the issue I will follow up with details.

Thanks,
Morduan Zang

[PATCH v2] iomap: guard io_size EOF trim against concurrent truncate underflow

[Morduan Zang]

iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:

    ioend->io_size += map_len;
    if (ioend->io_offset + ioend->io_size > end_pos)
        ioend->io_size = end_pos - ioend->io_offset;

However, if end_pos ends up below ioend->io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value.  This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().

A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.

Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.

Fixes: 51d20d1dacbe ("iomap: fix zero padding data issue in concurrent append writes")
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
---
Changes in v2:
- Adopt Christoph's suggested condition ordering for readability
- No runtime reproducer yet; still working on a test setup

v1: https://lore.kernel.org/all/863D407CB3ECEB04+20260618053820.506635-1-zhangdandan@uniontech.com/
---
 fs/iomap/ioend.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
index acf3cf98b23a..2d5611f6cc57 100644
--- a/fs/iomap/ioend.c
+++ b/fs/iomap/ioend.c
@@ -297,8 +297,12 @@ ssize_t iomap_add_to_ioend(struct iomap_writepage_ctx *wpc, struct folio *folio,
 	 * appending writes.
 	 */
 	ioend->io_size += map_len;
-	if (ioend->io_offset + ioend->io_size > end_pos)
-		ioend->io_size = end_pos - ioend->io_offset;
+	if (ioend->io_offset + ioend->io_size > end_pos) {
+		if (ioend->io_offset >= end_pos)
+			ioend->io_size = 0;
+		else
+			ioend->io_size = end_pos - ioend->io_offset;
+	}
 
 	wbc_account_cgroup_owner(wpc->wbc, folio, map_len);
 	return map_len;
-- 
2.50.1

Re: [PATCH v2] iomap: guard io_size EOF trim against concurrent truncate underflow

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Christian picked up the previous version, but I'd really prefer this
one if possible.