linux-kernel - Re: [RFC 5/5] ext4: mark group extend fast-commit ineligible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260119025857.GC19954@macsyma.local>
Date: Sun, 18 Jan 2026 16:58:57 -1000
From: "Theodore Tso" <tytso@....edu>
To: Li Chen <me@...ux.beauty>
Cc: Andreas Dilger <adilger.kernel@...ger.ca>,
        Steven Rostedt <rostedt@...dmis.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org
Subject: Re: [RFC 5/5] ext4: mark group extend fast-commit ineligible

On Thu, Dec 11, 2025 at 07:51:42PM +0800, Li Chen wrote:
> Fast commits only log operations that have dedicated replay support.
> EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last
> block group and updates the same on-disk metadata without going
> through the fast commit tracking paths.
> In practice these operations are rare and usually followed by further
> updates, but mixing them into a fast commit makes the overall
> semantics harder to reason about and risks replay gaps if new call
> sites appear.
> 
> Teach ext4 to mark the filesystem fast-commit ineligible when
> EXT4_IOC_GROUP_EXTEND grows the filesystem.
> This forces those transactions to fall back to a full commit,
> ensuring that the group extension changes are captured by the normal
> journal rather than partially encoded in fast commit TLVs.
> This change should not affect common workloads but makes online
> resize via GROUP_EXTEND safer and easier to reason about under fast
> commit.
> 
> Testing:
> 1. prepare:
>     dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256
>     mkfs.ext4 -O fast_commit -F /root/fc_resize.img
>     mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize
> 2. Extended the filesystem to the end of the last block group using a
>    helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem
>    and checked fc_info:
>     ./group_extend_helper /mnt/fc_resize
>     cat /proc/fs/ext4/loop0/fc_info
>    shows the "Resize" ineligible reason increased.
> 3. Fsynced a file on the resized filesystem and confirmed that the fast
>    commit ineligible counter incremented for the resize transaction:
>     touch /mnt/fc_resize/file
>     /root/fsync_file /mnt/fc_resize/file
>     sync
>     cat /proc/fs/ext4/loop0/fc_info
> 
> Signed-off-by: Li Chen <me@...ux.beauty>

I'm curious what version of the kernel you were testing against?  I
needed to mnake the final fix up to allow the patch to compile:

diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 9354083222b1..ce1f738dff93 100644
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -321,7 +321,8 @@ static int mext_move_extent(struct mext_data *mext, u64 *m_len)
 		ret = PTR_ERR(handle);
 		goto out;
 	}
-	ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_MOVE_EXT, handle);
+	ext4_fc_mark_ineligible(orig_inode->i_sb, EXT4_FC_REASON_MOVE_EXT,
+				handle);
 
 	ret = mext_move_begin(mext, folio, &move_type);
 	if (ret)

						- Ted