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] [day] [month] [year] [list]

Message-ID: <19bd642457a.3b9e5d002518428.1219702468395791363@linux.beauty>
Date: Mon, 19 Jan 2026 20:37:06 +0800
From: Li Chen <me@...ux.beauty>
To: "Theodore Tso" <tytso@....edu>
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" <linux-ext4@...r.kernel.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	"linux-trace-kernel" <linux-trace-kernel@...r.kernel.org>
Subject: Re: [RFC 5/5] ext4: mark group extend fast-commit ineligible

Hi Theodore,

Thanks for your reply.

 > 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:
 
I'm sorry I didn't mention the kernel version in the cover letter. This patchset is built against 7d0a66e4bb90 (tag: v6.18) Linux 6.18.

Regards,
Li

 > 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
 >