[PATCH AUTOSEL 6.19-5.15] ext4: mark group add fast-commit ineligible

[Sasha Levin <sashal@kernel.org>]

From: Li Chen <me@linux.beauty>

[ Upstream commit 89b4336fd5ec78f51f9d3a1d100f3ffa3228e604 ]

Fast commits only log operations that have dedicated replay support.
Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group
descriptor 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_ioctl_group_add() adds new block groups.
This forces those transactions to fall back to a full commit,
ensuring that the filesystem geometry updates 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_ADD 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. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted
   filesystem and checked the resize ineligible reason:
    ./group_add_helper /mnt/fc_resize
    cat /proc/fs/ext4/loop0/fc_info
   shows "Resize": > 0.
3. Fsynced a file on the resized filesystem and verified that the fast
   commit stats report at least one ineligible commit:
    touch /mnt/fc_resize/file
    /root/fsync_file /mnt/fc_resize/file
    sync
    cat /proc/fs/ext4/loop0/fc_info
   shows fc stats ineligible > 0.

Signed-off-by: Li Chen <me@linux.beauty>
Link: https://patch.msgid.link/20251211115146.897420-5-me@linux.beauty
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

So this is part of a series by the same author. There are three resize
paths:
1. `EXT4_IOC_RESIZE_FS` (already had `ext4_fc_mark_ineligible` from the
   original fast commit implementation)
2. `EXT4_IOC_GROUP_EXTEND` (fixed by `1f8dd813a1c77` - the companion
   commit)
3. `EXT4_IOC_GROUP_ADD` (fixed by this commit under review)

Both this commit and `1f8dd813a1c77` are from the same patch series
(patches 5 and 6 of the series based on the msgid link). They're
independent fixes to two different ioctl paths.

### 7. DEPENDENCY CHECK

This commit depends on:
- `EXT4_FC_REASON_RESIZE` existing in `fast_commit.h` — this was added
  in `aa75f4d3daaeb` (5.10 era, "ext4: main fast-commit commit path")
- The `ext4_fc_mark_ineligible()` API accepting `(sb, reason, NULL)` —
  the NULL handle variant was introduced in `e85c81ba8859a` which went
  to stable

The fast commit feature itself was added in Linux 5.10, so this fix
applies to 5.10+ stable trees. The API with 3 arguments (sb, reason,
handle) was introduced in `e85c81ba8859a` which was 5.17-era and was
already tagged Cc: stable. So the function signature should be available
in 5.15+ stable trees at minimum.

### SUMMARY

**What the commit fixes**: A missing fast-commit ineligibility marking
in the `EXT4_IOC_GROUP_ADD` resize path. Without this, filesystem
geometry changes from GROUP_ADD could be mixed with fast commits,
leading to potential filesystem inconsistency after crash recovery
because the fast commit replay has no dedicated handler for resize
operations.

**Severity**: Medium-high. While the scenario requires specific
conditions (fast_commit enabled + GROUP_ADD resize + crash timing), the
consequence is filesystem corruption/inconsistency, which is a data
integrity issue.

**Risk**: Extremely low. Single line addition that mirrors existing code
in the same file. The only effect is forcing a full journal commit
instead of fast commit during GROUP_ADD, which is the correct and safe
behavior. No regression possible.

**Meets stable criteria**:
- Obviously correct: YES (mirrors existing pattern)
- Fixes a real bug: YES (potential filesystem corruption on crash)
- Small and contained: YES (1 line)
- No new features: YES
- Already tested: YES

**Concern**: This is one of a pair of patches (the other being
`1f8dd813a1c77` for GROUP_EXTEND). Both should be backported together
for completeness, but each is independently valuable — they fix
different ioctl paths.

**YES**

 fs/ext4/ioctl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 7ce0fc40aec2f..5109b005e0286 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -966,6 +966,7 @@ static long ext4_ioctl_group_add(struct file *file,
 
 	err = ext4_group_add(sb, input);
 	if (EXT4_SB(sb)->s_journal) {
+		ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_RESIZE, NULL);
 		jbd2_journal_lock_updates(EXT4_SB(sb)->s_journal);
 		err2 = jbd2_journal_flush(EXT4_SB(sb)->s_journal, 0);
 		jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal);
-- 
2.51.0