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

[Christoph Hellwig <hch@infradead.org>]

On Thu, Jun 18, 2026 at 01:38:20PM +0800, Morduan Zang wrote:
> However, ioend can be created before a concurrent truncate shrinks
> the file.  In that case, end_pos can move below ioend->io_offset
> before the trim happens.  The subtraction then becomes negative, but
> the result is stored in size_t io_size, causing an unsigned wrap to
> a huge value.
> 
> 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.

Do you have examples for this?  I.e. did you hit this with a workload,
or did you just look over the code for issues?

> +	if (ioend->io_offset + ioend->io_size > end_pos) {
> +		if (end_pos > ioend->io_offset)
> +			ioend->io_size = end_pos - ioend->io_offset;
> +		else
> +			ioend->io_size = 0;
> +	}

I find this a bit hard to read due to different paramter ordering,
i.e. why not:

	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;
	}