From: Julian Sun sunjunchao@bytedance.com
[ Upstream commit 46e75c56dfeafb6756773b71cabe187a6886859a ]
The following code paths may result in high latency or even task hangs: 1. fastcommit io is throttled by wbt. 2. jbd2_fc_wait_bufs() might wait for a long time while JBD2_FAST_COMMIT_ONGOING is set in journal->flags, and then jbd2_journal_commit_transaction() waits for the JBD2_FAST_COMMIT_ONGOING bit for a long time while holding the write lock of j_state_lock. 3. start_this_handle() waits for read lock of j_state_lock which results in high latency or task hang.
Given the fact that ext4_fc_commit() already modifies the current process' IO priority to match that of the jbd2 thread, it should be reasonable to match jbd2's IO submission flags as well.
Suggested-by: Ritesh Harjani (IBM) ritesh.list@gmail.com Signed-off-by: Julian Sun sunjunchao@bytedance.com Reviewed-by: Zhang Yi yi.zhang@huawei.com Reviewed-by: Jan Kara jack@suse.cz Message-ID: 20250827121812.1477634-1-sunjunchao@bytedance.com Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES – aligning fast-commit writes with the journal’s request flags fixes real stall/hang scenarios without introducing new risk.
**Bug Impact** - When `ext4_fc_submit_bh()` tags fast-commit buffers with only `REQ_SYNC`, writeback throttling treats them as ordinary sync writes and can block them, triggering the long waits called out in the commit message; see the change at `fs/ext4/fast_commit.c:666`. - WBT explicitly exempts requests carrying both `REQ_SYNC` and `REQ_IDLE`, so the old flag set lets throttling kick in (`block/blk- wbt.c:606`), holding `JBD2_FAST_COMMIT_ONGOING`, which then stalls `jbd2_fc_wait_bufs()` (`fs/jbd2/journal.c:868-895`) and anything needing `j_state_lock`. That behavior matches the reported high latencies / task hangs.
**Why the Fix Is Safe** - `JBD2_JOURNAL_REQ_FLAGS` expands to `REQ_META | REQ_SYNC | REQ_IDLE` (`include/linux/jbd2.h:1372`), exactly what core journaling already uses for its writes (`fs/jbd2/commit.c:122`). Fast commits simply inherit the same metadata/high-priority treatment. - The change is a single-line adjustment confined to the fast-commit buffer submission path, with no format or architectural impact and no new dependencies (the macro has existed long before fast commits shipped). - Ext4 already boosts the committing task’s IO priority to match the journal thread (`fs/ext4/fast_commit.c:1211-1218`); matching the submission flags keeps behavior consistent and predictable.
Given the real-world stalls this resolves, the minimal and well- understood code change, and its tight scope within ext4 fast commits, it aligns with stable-tree rules and should be backported.
fs/ext4/fast_commit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index 42bee1d4f9f97..fa66b08de9994 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -663,7 +663,7 @@ void ext4_fc_track_range(handle_t *handle, struct inode *inode, ext4_lblk_t star
static void ext4_fc_submit_bh(struct super_block *sb, bool is_tail) { - blk_opf_t write_flags = REQ_SYNC; + blk_opf_t write_flags = JBD2_JOURNAL_REQ_FLAGS; struct buffer_head *bh = EXT4_SB(sb)->s_fc_bh;
/* Add REQ_FUA | REQ_PREFLUSH only its tail */