[PATCH AUTOSEL 6.18-5.10] hfsplus: fix volume corruption issue for generic/073

[Sasha Levin <sashal@kernel.org>]

From: Viacheslav Dubeyko <slava@dubeyko.com>

[ Upstream commit 24e17a29cf7537f0947f26a50f85319abd723c6c ]

The xfstests' test-case generic/073 leaves HFS+ volume
in corrupted state:

sudo ./check generic/073
FSTYP -- hfsplus
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025
MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/073 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent
(see XFSTESTS-2/xfstests-dev/results//generic/073.full for details)

Ran: generic/073
Failures: generic/073
Failed 1 of 1 tests

sudo fsck.hfsplus -d /dev/loop51
** /dev/loop51
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
Executing fsck_hfs (version 540.1-Linux).
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
Invalid directory item count
(It should be 1 instead of 0)
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000
CBTStat = 0x0000 CatStat = 0x00004000
** Repairing volume.
** Rechecking volume.
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume untitled was repaired successfully.

The test is doing these steps on final phase:

mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo

So, we move file bar from testdir_1 into testdir_2 folder. It means that HFS+
logic decrements the number of entries in testdir_1 and increments number of
entries in testdir_2. Finally, we do fsync only for testdir_1 and foo but not
for testdir_2. As a result, this is the reason why fsck.hfsplus detects the
volume corruption afterwards.

This patch fixes the issue by means of adding the
hfsplus_cat_write_inode() call for old_dir and new_dir in
hfsplus_rename() after the successful ending of
hfsplus_rename_cat(). This method makes modification of in-core
inode objects for old_dir and new_dir but it doesn't save these
modifications in Catalog File's entries. It was expected that
hfsplus_write_inode() will save these modifications afterwards.
However, because generic/073 does fsync only for testdir_1 and foo
then testdir_2 modification hasn't beed saved into Catalog File's
entry and it was flushed without this modification. And it was
detected by fsck.hfsplus. Now, hfsplus_rename() stores in Catalog
File all modified entries and correct state of Catalog File will
be flushed during hfsplus_file_fsync() call. Finally, it makes
fsck.hfsplus happy.

sudo ./check generic/073
FSTYP         -- hfsplus
PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc3+ #93 SMP PREEMPT_DYNAMIC Wed Nov 12 14:37:49 PST 2025
MKFS_OPTIONS  -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/073 32s ...  32s
Ran: generic/073
Passed all 1 tests

Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/20251112232522.814038-1-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my thorough analysis, here is my assessment:

---

## COMMIT ANALYSIS

### 1. PROBLEM DESCRIPTION
This commit fixes a **volume corruption issue** in HFS+ where renaming a
file between directories can lead to an inconsistent catalog file if
only one of the directories is subsequently fsync'd.

**The bug mechanism:**
1. When `hfsplus_rename()` moves a file from `old_dir` to `new_dir`, it
   calls `hfsplus_rename_cat()`
2. `hfsplus_rename_cat()` modifies both directories in memory:
   - `dst_dir->i_size++` (destination gains an entry)
   - `src_dir->i_size--` (source loses an entry)
   - Marks both dirty with `hfsplus_mark_inode_dirty()`
3. Marking dirty does NOT write to disk - it just flags for later
   writeback
4. If only one directory is fsync'd (as in xfstests generic/073), the
   other's changes may be lost
5. This creates a mismatch: the catalog file shows incorrect directory
   entry counts

**User-visible symptom:** `fsck.hfsplus` reports "Invalid directory item
count"

### 2. CODE CHANGE ANALYSIS

The fix is **extremely small and surgical** - only 5 lines added:

```c
- if (!res)
+   if (!res) {
        new_dentry->d_fsdata = old_dentry->d_fsdata;
+
+       res = hfsplus_cat_write_inode(old_dir);
+       if (!res)
+           res = hfsplus_cat_write_inode(new_dir);
+   }
```

**What it does:** After a successful rename, explicitly calls
`hfsplus_cat_write_inode()` for both directories, which writes their
catalog entries (including the valence/entry count) to the catalog file
immediately.

**Why it's correct:** `hfsplus_cat_write_inode()` is the established
function for writing directory catalog entries in HFS+. The fix ensures
both directories' updated entry counts are persisted immediately after
the rename operation.

### 3. CLASSIFICATION

| Criteria | Assessment |
|----------|------------|
| Bug type | **Filesystem corruption** - data integrity issue |
| Security | Not a CVE, but data corruption is serious |
| Cc: stable tag | **No** - maintainer didn't explicitly request
backport |
| Fixes: tag | **No** - no specific commit cited |
| User impact | HIGH for HFS+ users - volume corruption can cause data
loss |

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 5 lines added
- **Files touched:** 1 file (`fs/hfsplus/dir.c`)
- **Complexity:** Very low - adds two well-established function calls
- **Bug age:** Since 2013 (commit `892f6668f3a70` introduced
  `hfsplus_rename`)
- **Risk of regression:** **LOW** - the function being called is already
  used throughout HFS+ codebase

### 5. USER IMPACT

- **Who uses HFS+?** Mac users dual-booting, legacy Apple volumes, some
  embedded systems
- **Severity:** HIGH - filesystem corruption affects data integrity
- **Reproducibility:** Easily triggered by xfstests generic/073

### 6. DEPENDENCY CHECK

- `hfsplus_cat_write_inode()` has existed since the early days of
  hfsplus
- No dependency on other recent commits
- Should apply cleanly to all stable trees that include hfsplus

---

## VERDICT

**This commit SHOULD be backported** because:

1. **Fixes a real, serious bug:** Volume corruption is a significant
   data integrity issue
2. **Obviously correct:** The fix ensures both directories are written
   after rename - this is fundamental filesystem consistency
3. **Small and contained:** Only 5 lines in a single file, using
   existing functions
4. **Low regression risk:** Uses well-established
   `hfsplus_cat_write_inode()` function
5. **Long-standing bug:** Has affected users since 2013
6. **Reproducible:** Standard xfstests test case triggers the bug
7. **Follows established patterns:** Similar to how other filesystems
   handle rename consistency

While the commit lacks explicit "Cc: stable" and "Fixes:" tags, the
stable kernel rules clearly allow important bug fixes for data
corruption issues to be backported. The fix is minimal, well-understood,
and addresses a real problem that affects HFS+ users.

Sources:
- [xfstests generic test for fsync after renaming
  directory](https://patchwork.kernel.org/project/linux-
  btrfs/patch/1459330722-3227-1-git-send-email-fdmanana@kernel.org/)
- [xfstests GitHub repository](https://github.com/kdave/xfstests)

**YES**

 fs/hfsplus/dir.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/hfsplus/dir.c b/fs/hfsplus/dir.c
index 1b3e27a0d5e03..cadf0b5f93422 100644
--- a/fs/hfsplus/dir.c
+++ b/fs/hfsplus/dir.c
@@ -552,8 +552,13 @@ static int hfsplus_rename(struct mnt_idmap *idmap,
 	res = hfsplus_rename_cat((u32)(unsigned long)old_dentry->d_fsdata,
 				 old_dir, &old_dentry->d_name,
 				 new_dir, &new_dentry->d_name);
-	if (!res)
+	if (!res) {
 		new_dentry->d_fsdata = old_dentry->d_fsdata;
+
+		res = hfsplus_cat_write_inode(old_dir);
+		if (!res)
+			res = hfsplus_cat_write_inode(new_dir);
+	}
 	return res;
 }
 
-- 
2.51.0