DF-2765 — journal_nrename records post-rename namecache paths: the source path is never journaled (PATH1 == PATH2)

What

journal_nrename() (sys/kern/vfs_jops.c:1301-1328) writes its REDO path leaves AFTER vop_journal_operate_ap() (:1318). But a successful underlying rename calls cache_rename(ap->a_fnch, ap->a_tnch) (sys/kern/vfs_cache.c:2085-2142, called from every nrename implementation, e.g. sys/kern/vfs_default.c:1064), which relinks the SOURCE ncp to the target name in place (fncp->nc_name = nname, :2118-2120) and destroys the target ncp (_cache_unlink(tncp), :2141).

So the post-op walk records: - JLEAF_PATH1 from ap->a_fnch->ncp = the target path (post-rename), - JLEAF_PATH2 from ap->a_tnch->ncp = the target path again,

and the original (source) path never enters the journal stream. A mirror/replica replaying rename records cannot reconstruct the operation (it degenerates to rename(new,new)), silently diverging from the master; reversable-journal rollback of a rename is likewise impossible.

PoC (reproduced first try, stock kernel)

mkdir -p /tmp/jt/a /tmp/jt/b; echo hi > /tmp/jt/a/src.txt   # BEFORE journal install
mountctl -a -w /root/jr.bin -o memfifo=64k /tmp:rename1      # root
mv /tmp/jt/a/src.txt /tmp/jt/b/dst.txt
mountctl -d /tmp:rename1
# decode /root/jr.bin (see run.log + decode.py)

Observed in the 192-byte stream (raw hex @0x60 and @0x78): - JLEAF_PATH1 (0x0402) = "jt/b/dst.txt\0" - JLEAF_PATH2|LAST (0x4403) = "jt/b/dst.txt\0" - string "jt/a/src.txt" occurs 0 times in the entire stream.

Fix

Capture PATH1 before the op (validated in the DF-2763 fix kernel): write JLEAF_PATH1 from ap->a_fnch->ncp between jreclist_init and vop_journal_operate_ap(); on op failure the stream is aborted by jreclist_done() so the pre-op write costs nothing. See fix.diff.

Fix validation (kernel #2, same build as DF-2763)

Re-run of df2765_run.sh on the patched kernel: stream now contains BOTH paths — 'jt/a/src.txt' (PATH1, captured pre-op, count 1) and 'jt/b/dst.txt' (PATH2, count 1). Baseline stream had the source path 0 times / target twice. See run_fixed.log, journal_stream_fixed.bin.

DF-2765 — VERDICT

Status: reproduced (first run), fix validated.

Baseline (stock kernel)

Journal installed on /tmp (tmpfs); rename of /tmp/jt/a/src.txt -> /tmp/jt/b/dst.txt through the shim; stream decoded:

• RAW sid=0xc100 (JREC_STREAMCTL_BEGIN|END, streamid 0x100) = the JTYPE_RENAME transaction.
• PATH1 leaf (0x0402) @0x60 = "jt/b/dst.txt\0"
• PATH2 leaf|LAST (0x4403) @0x78 = "jt/b/dst.txt\0"
• "jt/a/src.txt" count in the whole 192-byte stream: 0

Root cause: journal_nrewrite records both paths AFTER vop_journal_operate_ap (vfs_jops.c:1322-1323); the underlying nrename calls cache_rename (vfs_cache.c:2085) which relinks fnch->ncp to the target name in-place (:2118-2120) and unlinks tnch->ncp (:2141). The source path is thereby unobservable after the op.

Fix (validated on kernel #2)

PATH1 written from ap->a_fnch->ncp between jreclist_init and the op (hunk 4 of fix.diff). On op failure the whole stream is aborted by jreclist_done(error), so the pre-op write is free. Post-fix stream: source count 1, target count 1. run_fixed.log + journal_stream_fixed.bin.

Impact

Journal-record correctness: replicas/mirrors replaying rename records degenerate to rename(new,new) and silently diverge; reversable-journal undo of renames is impossible. Requires a root-installed journal; trigger is any rename on the journaled mount (unprivileged ok). Severity Low.