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

[Zhang Yi <yizhang089@gmail.com>]

On 9/3/2026 9:40 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] Single-threaded workqueue stall causing filesystem-wide deadlock on concurrent write and writeback due to WB_SYNC_NONE skipping locked folios.
> --

I don't think this case can happen. A folio which is temporarily locked
by a writer is not skipped: writeback_get_folio() takes the folio lock
with a blocking folio_lock(), and the only folio WB_SYNC_NONE drops is
one already under writeback, i.e. whose I/O has already been submitted
with EXT4_IOMAP_IOEND_DISKSIZE_GROW_IO set (the flag is applied at
submission time in ext4_iomap_writeback_submit()), so the state is
cleared in ext4_iomap_end_bio().  That clearing happens in the bio
completion path, in softirq context, not in the rsv_conversion worker,
so a blocked worker cannot prevent it.

The jbd2 link doesn't hold either: inodes on the iomap buffered I/O path
do not use data=ordered, so they are never added to the transaction's
ordered list and journal_finish_inode_data_buffers() never waits for
their PG_writeback.

Thanks,
Yi.

> 
> commit 8015bea7c1654bcaea86ce738fcb50400fa35290
> Author: Zhang Yi <yi.zhang@huawei.com>
> 
> ext4: submit and wait for pending disksize-grow I/O on writeback
> 
> This commit introduces a mechanism to proactively submit and wait for pending
> disksize-grow zeroed EOF blocks during writeback. This prevents stale data
> exposure when advancing i_disksize.
> 
>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>> index 383824e89d123..4c2b6cd15d1f9 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
> [ ... ]
>> +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;
> [ ... ]
>> +	/* 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: Critical]
> Could this WB_SYNC_NONE flush silently skip a locked folio, leaving the pending
> EOF block unsubmitted?
> 
> If a user-space thread is concurrently modifying a folio covering the pending
> zeroed EOF block (which has EXT4_STATE_DISKSIZE_GROW_PENDING set), the folio
> will be temporarily locked.
> 
> When background writeback (kupdate) flushes a subsequent range, it will call
> filemap_flush_range() here, which uses WB_SYNC_NONE and skips locked folios
> without submitting their I/O.
> 
>> 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: Critical]
> Does this wait cause a permanent filesystem-wide deadlock if the pending EOF
> block was skipped during WB_SYNC_NONE?
> 
> If the locked EOF folio was skipped by ext4_iomap_wb_submit_zeroed_eof(), the
> I/O for the subsequent range will complete and queue its ioend on the
> single-threaded sbi->rsv_conversion_wq. The worker thread will unconditionally
> block here waiting for the unsubmitted EOF block's I/O to complete.
> 
> This stalls the entire workqueue. Later, the jbd2 commit thread runs and blocks
> in filemap_fdatawait() waiting for the PG_writeback bit of the subsequent range
> to clear, which only happens at the end of ext4_iomap_finish_ioend() via
> iomap_finish_ioends().
> 
> Finally, kupdate attempts to write another file with delayed allocation,
> blocking in ext4_journal_start() waiting for jbd2. Because kupdate is now
> deadlocked, it will never loop back to write out the skipped EOF folio,
> resulting in a permanent circular deadlock.
>