Re: [PATCH v7 22/31] ext4: submit and wait for pending disksize-grow I/O on writeback

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ext4: multi-second stall in rsv_conversion_wq due to skipped locked folio
--

commit effefa308fc467b9330490d20efb3b9b03f85c73
Author: Zhang Yi <yi.zhang@huawei.com>

ext4: submit and wait for pending disksize-grow I/O on writeback

This commit introduces the ioend mechanism for the pending disksize-grow
I/O range. It attempts to proactively submit the pending range in
ext4_iomap_writepages() so it completes in parallel, and waits for its
completion in the ioend finish path to avoid exposing stale data when
advancing i_disksize.

> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 9c45a0c01d1c1..76e070eaa6f89 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
[ ... ]
> @@ -4404,6 +4422,36 @@ static const struct iomap_writeback_ops ext4_writeback_ops = {
>  	.writeback_submit = ext4_iomap_writeback_submit,
>  };
>  
> +/*
> + * If the current writeback range begins after the pending zeroed EOF
> + * block range which straddles i_disksize, issue a separate writeback to
> + * flush it first, so as to avoid prolonged waiting.
> + */
> +static void ext4_iomap_wb_submit_zeroed_eof(struct inode *inode,
> +					    struct writeback_control *wbc)
> +{
> +	struct address_space *mapping = inode->i_mapping;
> +	loff_t pstart, plen, range_start;
> +
> +	if (wbc->range_cyclic)
> +		range_start = (loff_t)mapping->writeback_index << PAGE_SHIFT;
> +	else
> +		range_start = wbc->range_start;
> +
> +	plen = ext4_iomap_get_disksize_pending_range(inode, &pstart);
> +	if (!plen)
> +		return;
> +	if (round_down(range_start, mapping_min_folio_nrbytes(mapping)) <
> +	    pstart + plen)
> +		return;
> +
> +	/* Keep the caller's sync mode to avoid stalling the background flusher. */
> +	if (wbc->sync_mode == WB_SYNC_ALL)
> +		filemap_fdatawrite_range(mapping, pstart, pstart + plen - 1);
> +	else
> +		filemap_flush_range(mapping, pstart, pstart + plen - 1);

[Severity: High]
Does this code risk skipping locked folios and causing a stall later?

If wbc->sync_mode is WB_SYNC_NONE, filemap_flush_range() is used, which
skips folios that are locked by other threads without returning an error.
If the pending zeroed EOF folio is transiently locked (for example, by a
concurrent buffered read or write), it will be skipped and remain dirty,
and its pending bit will not be cleared.

However, the main writeback pass will continue and submit I/O for subsequent
folios in the file.

> +}
> +
>  static int ext4_iomap_writepages(struct address_space *mapping,
[ ... ]
> diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
> index 9b0e12b5463cf..697e12a54a49a 100644
> --- a/fs/ext4/page-io.c
> +++ b/fs/ext4/page-io.c
[ ... ]
> @@ -594,6 +622,9 @@ static void ext4_iomap_finish_ioend(struct iomap_ioend *ioend)
>  	    end <= READ_ONCE(EXT4_I(inode)->i_disksize))
>  		goto out;
>  
> +	/* Wait for disksize-pending zeroed data to be written out. */
> +	ext4_iomap_wb_disksize_pending_wait(inode, pos, size);
> +

[Severity: High]
Can this wait block the rsv_conversion_wq indefinitely?

When the subsequent IOs complete, ext4_iomap_finish_ioend() runs in the
single-threaded rsv_conversion_wq. It calls
ext4_iomap_wb_disksize_pending_wait(), which waits for the pending bit
to be cleared.

If the pending block was silently skipped earlier by filemap_flush_range(),
the bit will not be cleared until the skipped folio is written by a future
writeback pass. During this time, the entire filesystem's I/O conversions
are stalled, potentially causing massive latency spikes or deadlocking memory
reclaim.

>  	/*
>  	 * We may need to convert one extent, update the i_disksize and
>  	 * dirty the inode.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009103033.2920530-1-yi.zhang@huaweicloud.com?part=22