In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2cleanupjournaltail() returns error In jbd2logwaitforspace(), we might call jbd2cleanupjournaltail() to recover some journal space. But if an error occurs while executing jbd2cleanupjournaltail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if jcommittingtransaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. _jbd2logwaitforspace: needed 256 blocks and only had 217 space available _jbd2logwaitforspace: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 _jbd2logwaitforspace+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:jbd2logwaitforspace+0x251/0x2e0 Call Trace: <TASK> addtransactioncredits+0x5d1/0x5e0 startthishandle+0x1ef/0x6a0 jbd2_journalstart+0x18b/0x340 ext4dirtyinode+0x5d/0xb0 _markinodedirty+0xe4/0x5d0 genericupdatetime+0x60/0x70 [...] ============================================ So only if jbd2cleanupjournaltail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2cleanupjournal_tail return the correct error code.