From: Luyao Bai <bailuyao1997@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.cz>, Baokun Li <libaokun@linux.alibaba.com>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
Zhang Yi <yi.zhang@huawei.com>,
"Darrick J . Wong" <djwong@kernel.org>,
Christian Brauner <brauner@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH] ext4: do not WARN when starting a journal on a frozen filesystem
Date: Thu, 23 Jul 2026 20:50:36 +0000 [thread overview]
Message-ID: <20260723205036.661832-1-bailuyao1997@gmail.com> (raw)
A WARNING is triggered in ext4_journal_check_start() when a background
writeback thread attempts to start a journal transaction while the
filesystem is in the SB_FREEZE_COMPLETE state:
WARNING: CPU: 1 PID: 2903 at fs/ext4/ext4_jbd2.c:76
ext4_journal_check_start+0x1f8/0x250
Call Trace:
__ext4_journal_start_sb+0x181/0x600 fs/ext4/ext4_jbd2.c:105
__ext4_journal_start fs/ext4/ext4_jbd2.h:326 [inline]
ext4_do_writepages+0x112c/0x3d20 fs/ext4/inode.c:2707
ext4_writepages+0x213/0x3c0 fs/ext4/inode.c:2813
do_writepages+0x35f/0x870 mm/page-writeback.c:2683
__writeback_single_inode+0x14f/0x10d0 fs/fs-writeback.c:1658
writeback_sb_inodes+0x80c/0x1370 fs/fs-writeback.c:1954
wb_writeback+0x41b/0xbd0 fs/fs-writeback.c:2134
wb_workfn+0x410/0x1090 fs/fs-writeback.c:2321
The background writeback flusher does not take freeze protection, so it
can legitimately reach ext4_do_writepages() and try to start a journal
handle while the filesystem is frozen. This happens, for example, when
ext4_writepages() failed earlier (e.g. -ENOSPC or -EDQUOT) during the
sync_filesystem() phase of the freeze: sync_filesystem() can still
return 0, the freeze completes, but dirty pages are left behind. A later
writeback pass then tries to write them out on the now-frozen
filesystem.
The same state is reachable through the EXT4_IOC_SHUTDOWN path: if
fs_bdev_freeze() succeeds in freezing the superblock but the subsequent
sync_blockdev() fails, the filesystem is left in SB_FREEZE_COMPLETE and
dirty pages remain, so writeback eventually retries and trips the WARN.
Because this state can be reached without any kernel bug, WARN_ON() is
the wrong tool here: WARN_ON() must only fire on conditions that should
never happen. Replace it with an ext4_msg() error message and return
-EROFS, rejecting the transaction cleanly. All callers of
__ext4_journal_start_sb() already handle an error return (it is the same
path used for the existing is_journal_aborted() -EROFS case), so the
dirty pages are simply kept and written back once the filesystem is
thawed.
This patch is intentionally limited to the ext4 journal-start check,
which is the direct cause of the reported warning. Any improvements to
the generic VFS freeze/thaw error handling in fs/super.c are a separate
concern and are deliberately left out of this fix.
Reported-by: syzbot+b75d75f957975f3d40e3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b75d75f957975f3d40e3
Fixes: 49ef8832fb1a ("bdev: implement freeze and thaw holder operations")
Signed-off-by: Luyao Bai <bailuyao1997@gmail.com>
---
Tested with the syzbot reproducer under QEMU: the WARNING at
fs/ext4/ext4_jbd2.c fires on a clean mainline build and no longer fires
with this patch applied.
fs/ext4/ext4_jbd2.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
index 9a8c225f2..1756039b1 100644
--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -75,7 +75,12 @@ static int ext4_journal_check_start(struct super_block *sb)
if (WARN_ON_ONCE(sb_rdonly(sb)))
return -EROFS;
- WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);
+ if (unlikely(sb->s_writers.frozen == SB_FREEZE_COMPLETE)) {
+ ext4_msg(sb, KERN_ERR,
+ "Attempt to start a journal transaction on a frozen filesystem");
+ return -EROFS;
+ }
+
journal = EXT4_SB(sb)->s_journal;
/*
* Special case here: if the journal has aborted behind our
--
2.43.0
next reply other threads:[~2026-07-23 20:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 20:50 Luyao Bai [this message]
2026-07-24 8:11 ` Christian Brauner
2026-07-24 13:31 ` Theodore Tso
2026-07-24 14:16 ` Luyao Bai
2026-07-24 14:32 ` Theodore Tso
2026-07-28 13:45 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260723205036.661832-1-bailuyao1997@gmail.com \
--to=bailuyao1997@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®