[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251025160905.3857885-302-sashal@kernel.org>
Date: Sat, 25 Oct 2025 11:58:53 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
stable@...r.kernel.org
Cc: Julian Sun <sunjunchao@...edance.com>,
"Ritesh Harjani (IBM)" <ritesh.list@...il.com>,
Zhang Yi <yi.zhang@...wei.com>,
Jan Kara <jack@...e.cz>,
Theodore Ts'o <tytso@....edu>,
Sasha Levin <sashal@...nel.org>,
adilger.kernel@...ger.ca,
linux-ext4@...r.kernel.org
Subject: [PATCH AUTOSEL 6.17-6.1] ext4: increase IO priority of fastcommit
From: Julian Sun <sunjunchao@...edance.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@...il.com>
Signed-off-by: Julian Sun <sunjunchao@...edance.com>
Reviewed-by: Zhang Yi <yi.zhang@...wei.com>
Reviewed-by: Jan Kara <jack@...e.cz>
Message-ID: <20250827121812.1477634-1-sunjunchao@...edance.com>
Signed-off-by: Theodore Ts'o <tytso@....edu>
Signed-off-by: Sasha Levin <sashal@...nel.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 */
--
2.51.0
Powered by blists - more mailing lists