Re: [PATCH v6 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:
- [Critical] Single-threaded workqueue stall causing filesystem-wide deadlock on concurrent write and writeback due to WB_SYNC_NONE skipping locked folios.
--

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.

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