[PATCH AUTOSEL 6.18-6.12] btrfs: use on-disk uuid for s_uuid in temp_fsid mounts
From: Sasha Levin
Date: Mon Aug 31 2026 - 13:25:00 EST
From: Anand Jain <asj@xxxxxxxxxx>
[ Upstream commit df84f6c773771fa7b78fe06931709df1aca5907f ]
When mounting a cloned filesystem with a temporary fsuuid (temp_fsid),
layered modules like overlayfs require a persistent identifier.
While internal in-memory fs_devices->fsid must remain unique to
the kernel module, let s_uuid carry the original on-disk UUID.
Signed-off-by: Anand Jain <asj@xxxxxxxxxx>
Signed-off-by: David Sterba <dsterba@xxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
**Step 1.1 — Subject line**
- Record: `[btrfs] [use] use on-disk uuid for s_uuid in temp_fsid
mounts` — fixes incorrect `sb->s_uuid` assignment when btrfs’s in-
memory `temp_fsid` feature is active.
**Step 1.2 — Tags**
- Record: `Signed-off-by: Anand Jain <asj@xxxxxxxxxx>`, `Signed-off-by:
David Sterba <dsterba@xxxxxxxx>`
- No `Fixes:`, `Reported-by:`, `Cc: stable`, `Tested-by:`, `Reviewed-
by:`, or `Link:` tags (expected for manual review candidates).
- Notable: David Sterba (btrfs maintainer) signed off.
**Step 1.3 — Body analysis**
- Record: **Bug**: When mounting a cloned btrfs image with `temp_fsid`,
`sb->s_uuid` was set from the random in-memory `fs_devices->fsid`, not
the on-disk UUID. **Symptom**: Layered filesystems (overlayfs) that
rely on a persistent `s_uuid` break — remounting the same image fails
origin verification. **Root cause**: `temp_fsid` intentionally
randomizes `fs_devices->fsid` for kernel uniqueness, but that value
was incorrectly propagated to `sb->s_uuid`. **Fix**: For `temp_fsid`
mounts, copy the on-disk UUID from `super_copy->fsid` into
`sb->s_uuid`.
**Step 1.4 — Hidden bug fix?**
- Record: Yes. Despite not using “fix” in the subject, this is a
functional correctness bug in how btrfs exposes filesystem identity to
the VFS and overlayfs.
---
## Phase 2: Diff Analysis
**Step 2.1 — Inventory**
- Record: `fs/btrfs/disk-io.c`: +10 / −1 lines. Function:
`open_ctree()`. Scope: single-file surgical fix.
**Step 2.2 — Code flow change**
- Record:
- **Before**: `memcpy(&sb->s_uuid, fs_info->fs_devices->fsid, ...)`
always — for `temp_fsid`, this is a per-mount random UUID.
- **After**: If `temp_fsid`, use `fs_info->super_copy->fsid` (on-
disk); otherwise unchanged behavior.
- **Path**: Normal mount path in `open_ctree()`, after `super_copy` is
populated (line 3344) and before chunk root read.
**Step 2.3 — Bug mechanism**
- Record: **Logic/correctness fix**. `sb->s_uuid` must reflect
persistent filesystem identity; `fs_devices->fsid` is intentionally
volatile under `temp_fsid`. Wrong identifier exposed to VFS consumers.
**Step 2.4 — Fix quality**
- Record: Obviously correct — `super_copy` is already populated and
validated at this point. Minimal change, no API changes. Low
regression risk; non-`temp_fsid` path unchanged.
---
## Phase 3: Git History Investigation
**Step 3.1 — Blame**
- Record: `memcpy(&sb->s_uuid, ...)` introduced by Nikolay Borisov
(2018-10-30, commit `de37aa513105f8`). `temp_fsid` introduced by Anand
Jain in `a5b8a5f9f8355` (“btrfs: support cloned-device mount
capability”, merged Oct 2023, first in **v6.7**). Bug present since
v6.7 whenever both features coexist.
**Step 3.2 — Fixes: tag**
- Record: N/A — no `Fixes:` tag.
**Step 3.3 — Related history**
- Record: Part of v3 series `[PATCH v3 0/2] fix s_uuid and f_fsid
consistency for cloned filesystems`. Companion patch 2/2
(`c2a74ed0494c2`) fixes `f_fsid` in `btrfs_statfs()` — separate
concern (statfs/fanotify/ima). This commit (patch 1/2) is standalone
for the `s_uuid`/overlayfs issue.
**Step 3.4 — Author context**
- Record: Anand Jain is an active btrfs contributor; David Sterba
(maintainer) reviewed and signed off.
**Step 3.5 — Dependencies**
- Record: Requires `temp_fsid` support (present since v6.7). Requires
`fs_info->super_copy` (long-standing). No other commits needed for
this hunk. `git apply --check` on the patch against 6.18.44 succeeds.
---
## Phase 4: Mailing List and External Research
**Step 4.1 — Original discussion**
- Record: b4 dig found `[PATCH v3 1/2]` at https://patch.msgid.link/b4b5
637ca4137d71eba368e37c67abcf60df0cab.1777281686.git.asj@xxxxxxxxxx
- Series: v1 → v2 → v3 (latest applied version).
**Step 4.2 — Reviewers**
- Record: CC’d to `linux-btrfs@xxxxxxxxxxxxxxx`, `dsterba@xxxxxxxx`.
David Sterba replied on patch 2/2 with changelog corrections (May
2026).
**Step 4.3 — Bug report**
- Record: Cover letter references André Almeida’s overlayfs report:
https://lore.kernel.org/linux-
btrfs/20251014015707.129013-1-andrealmeid@xxxxxxxxxx
- **Reproduction** (verified from mbox): `mkfs.btrfs`, clone image,
mount twice, use overlayfs with `index=on` — second mount of same
image fails because btrfs assigns a new random `temp_fsid` UUID each
mount while overlayfs stores/compares `s_uuid` in `overlay.origin`.
- **dmesg**: `"failed to verify upper root origin"`
- Christoph Hellwig: “Please fix btrfs to not change uuids, as that
completely defeats the point of uuids.”
**Step 4.4 — Series context**
- Record: Patch 2/2 (`c2a74ed0494c2`) addresses `f_fsid` via statfs for
fanotify/ima — not required for this commit’s overlayfs `s_uuid` fix
but addresses related instability.
**Step 4.5 — Stable discussion**
- Record: No explicit `Cc: stable` found in thread. Not a negative
signal.
---
## Phase 5: Code Semantic Analysis
**Step 5.1 — Modified functions**
- Record: `open_ctree()` in `fs/btrfs/disk-io.c`.
**Step 5.2 — Callers**
- Record: `open_ctree()` is called during btrfs mount
(`btrfs_fill_super` / `btrfs_get_tree`). Every btrfs mount goes
through this path.
**Step 5.3 — Key callees at change site**
- Record: Uses already-populated `fs_info->super_copy` and
`fs_info->fs_devices->temp_fsid`. No new allocations or locks.
**Step 5.4 — Reachability**
- Record: Triggered by any user mounting a cloned btrfs device while
another instance with the same on-disk UUID is already registered —
exactly the `temp_fsid` use case (since v6.7). Unprivileged users can
trigger via mount namespaces / loop devices.
**Step 5.5 — Similar patterns**
- Record: Patch 2/2 applies the same `super_copy->fsid` principle to
`btrfs_statfs()` `f_fsid`. The `temp_fsid` design in `volumes.h`
documents that in-memory `fsid` is random while `metadata_uuid ==
sb->fsid`.
---
## Phase 6: Cross-Reference Against Local Tree (6.18.44)
**Step 6.1 — Buggy code present?**
- Record: **Yes.** Tree is `v6.18.44` (`stable/linux-6.18.y`). Line 3428
in `disk-io.c` still has the buggy unconditional `memcpy`. `temp_fsid`
feature confirmed present (`git merge-base --is-ancestor a5b8a5f9f8355
HEAD` → yes, since v6.7).
**Step 6.2 — Backport complications**
- Record: **Clean apply.** `git show df84f6c773771 -- fs/btrfs/disk-io.c
| git apply --check` succeeds on current HEAD. No conflicting recent
churn at this location.
**Step 6.3 — Related fixes already present?**
- Record: **No.** Neither `df84f6c773771` (this commit) nor
`c2a74ed0494c2` (companion f_fsid fix) are ancestors of HEAD.
---
## Phase 7: Subsystem and Maintainer Context
**Step 7.1 — Subsystem**
- Record: `fs/btrfs` — IMPORTANT (widely deployed filesystem, container
rootfs stacks).
**Step 7.2 — Activity**
- Record: btrfs actively maintained in 6.18.y; `temp_fsid` is a shipped
feature since 6.7.
---
## Phase 8: Impact and Risk Assessment
**Step 8.1 — Who is affected**
- Record: Users combining btrfs cloned-device mounts (`temp_fsid`) with
overlayfs `index=on` (common in container/OCI immutable-root
workflows).
**Step 8.2 — Trigger conditions**
- Record: Mount same btrfs clone image twice; use overlayfs with
`index=on` on second mount. Reproducible, documented. Not timing-
dependent.
**Step 8.3 — Failure mode severity**
- Record: **Mount failure** — overlayfs refuses to mount with `"failed
to verify upper root origin"`. Breaks remount of unchanged images.
Severity: **MEDIUM** (functional breakage, not
crash/corruption/security, but breaks a real documented workflow).
**Step 8.4 — Risk-benefit**
- Record: **Benefit**: HIGH for affected btrfs+overlayfs users (restores
expected remount behavior). **Risk**: VERY LOW (10 lines, conditional
on `temp_fsid`, non-temp path unchanged). **Ratio**: Favorable.
---
## Phase 9: Final Synthesis
**Step 9.1 — Evidence summary**
FOR backport:
- Real, documented bug (André Almeida RFC, Oct 2025) with reproduction
script
- Maintainer-signed fix (David Sterba)
- Small, surgical, applies cleanly to 6.18.44
- Bug exists in this tree since `temp_fsid` landed (v6.7)
- Directly fixes overlayfs `s_uuid` comparison in `ovl_decode_real_fh()`
/ origin verification
- btrfs maintainer community agreed btrfs should expose stable UUIDs
AGAINST backport:
- Not a crash, data corruption, or security issue — functional mount
failure only
- Part of 2-patch series (patch 2/2 for `f_fsid`/statfs is separate;
ideally backported too but not a prerequisite for this fix)
- Affects a specific feature combination (btrfs clone + overlayfs index)
**Step 9.2 — Stable rules checklist**
1. Obviously correct and tested? **PASS** — logic is clear; maintainer
SOB; applies cleanly.
2. Fixes a real bug affecting users? **PASS** — documented overlayfs
remount failure.
3. Important issue? **PASS (MEDIUM)** — mount failure breaking overlayfs
`index=on` with btrfs clones; not crash/corruption but real user
impact.
4. Small and contained? **PASS** — 10 lines, one file, one function.
5. No new features or APIs? **PASS** — corrects existing `s_uuid`
semantics.
6. Can apply to local tree? **PASS** — verified clean apply.
**Step 9.3 — Exception categories**
- Record: None (not device ID, quirk, DT, build, or docs). Standard bug
fix.
**Step 9.4 — Decision rationale**
This commit fixes a real functional regression introduced when btrfs’s
`temp_fsid` feature (present in 6.18.y since v6.7) started exposing a
per-mount random UUID via `sb->s_uuid`. Overlayfs with `index=on` stores
and later verifies that UUID; remounting the same btrfs clone image
fails with `"failed to verify upper root origin"`. The fix is minimal,
maintainer-approved, and applies cleanly to the 6.18.44 tree. While not
a crash or corruption issue, it restores correct behavior for a
supported btrfs+overlayfs combination that btrfs maintainers explicitly
addressed.
Note: The companion commit `c2a74ed0494c2` (f_fsid/statfs stability)
addresses a related but separate symptom and should be evaluated
independently.
---
## Verification
- [Phase 1] `git show df84f6c773771`: parsed commit message and tags
- [Phase 2] Diff: 10 insertions, 1 deletion in `open_ctree()`;
conditional on `temp_fsid`
- [Phase 3] `git describe HEAD`: v6.18.44; `git blame` line 3428:
`de37aa513105f8` (2018); `temp_fsid` from `a5b8a5f9f8355` (v6.7)
- [Phase 3] `git merge-base --is-ancestor a5b8a5f9f8355 HEAD`: temp_fsid
IS in 6.18.y
- [Phase 3] `git merge-base --is-ancestor df84f6c773771 HEAD`: patch NOT
in tree
- [Phase 3] `git show df84f6c773771 -- fs/btrfs/disk-io.c | git apply
--check`: clean apply
- [Phase 4] `b4 dig -c df84f6c773771`: found v3 series at
lore.kernel.org
- [Phase 4] `b4 dig -c df84f6c773771 -a`: v1/v2/v3 revisions; patch 1/2
of 2-patch series
- [Phase 4] `b4 dig -c df84f6c773771 -w`: CC linux-btrfs,
dsterba@xxxxxxxx
- [Phase 4] curl lore mbox for overlayfs RFC: confirmed reproduction and
`"failed to verify upper root origin"` failure mode
- [Phase 4] Cover letter: references Christoph Hellwig “fix btrfs to not
change uuids”
- [Phase 5] `grep s_uuid fs/overlayfs/`: overlayfs uses
`mnt->mnt_sb->s_uuid` in `ovl_decode_real_fh()` (namei.c:176) and
copy_up.c:424
- [Phase 5] `open_ctree()` called on every btrfs mount
- [Phase 6] Current `disk-io.c:3428`: buggy code confirmed present
- [Phase 6] `super_copy` populated at line 3344, before s_uuid
assignment at 3428
- [Phase 8] Failure mode: overlayfs mount refusal on remount, severity
MEDIUM
**YES**The background searches finished and matched what the full
analysis used:
- **Commit identified:** `df84f6c773771` — *btrfs: use on-disk uuid for
s_uuid in temp_fsid mounts*
- **On master, not in 6.18.44:** neither this commit nor its series mate
are in the current stable tree
- **Companion patch:** `c2a74ed0494c2` — *btrfs: derive f_fsid from on-
disk fsid and dev_t* (patch 2/2; separate `statfs`/`f_fsid` fix)
**Verdict for 6.18.y: YES** — small, maintainer-signed fix for overlayfs
`index=on` remount failures with btrfs cloned mounts; applies cleanly.
Consider evaluating patch 2/2 separately for `statfs`/`f_fsid`
stability.
fs/btrfs/disk-io.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 655eed981078b..1664b22961ee0 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3425,7 +3425,16 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
/* Update the values for the current filesystem. */
sb->s_blocksize = sectorsize;
sb->s_blocksize_bits = blksize_bits(sectorsize);
- memcpy(&sb->s_uuid, fs_info->fs_devices->fsid, BTRFS_FSID_SIZE);
+ /*
+ * When temp_fsid is active, fs_devices->fsid is assigned a random UUID
+ * at mount. This inconsistent UUID causes issues for layered filesystems
+ * like OverlayFS. Since metadata_uuid may or may not be set, provide the
+ * on-disk UUID directly from the super_copy.
+ */
+ if (fs_info->fs_devices->temp_fsid)
+ memcpy(&sb->s_uuid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE);
+ else
+ memcpy(&sb->s_uuid, fs_info->fs_devices->fsid, BTRFS_FSID_SIZE);
mutex_lock(&fs_info->chunk_mutex);
ret = btrfs_read_sys_array(fs_info);
--
2.53.0