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

[Zhang Yi <yizhang089@gmail.com>]

On 10/9/2026 7:18 PM, sashiko-bot@kernel.org wrote:
> 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
> --

This is a false positive again, for the same reason as in the v6
iteration.

Thanks,
Yi.

> 
> 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.
>