=== DF-0824 FIX VALIDATION — single-fix ext2fs.ko module (patched) ===
guest: DragonFly dfbsd 6.5-DEVELOPMENT #0 (kernel unchanged — ext2fs is a loadable module)
module: /boot/kernel/ext2fs.ko sha256=7cb9b301950e7e7972c05bc4a85f0df5f583e930fbabf8882bb8381d22d33ba0
       (rebuilt from patched sys/vfs/ext2fs/ext2_lookup.c with EXT2_CHECKPATH_MAXDEPTH=256)
trigger: same image (df0824.img) + same rename as baseline

=== RUN 1 (patched module) ===
sh /root/df0824_trigger.sh /root/df0824.img
...
=== running: mv S A/S_moved (bounded by timeout 8) ===
mv: rename S to A/S_moved: Invalid argument
(rename returned promptly; depth cap tripped -> EINVAL; no kernel hang)

=== RUN 2 (direct, timed) ===
=== RUN 2 ===
mv: rename S to A/S_moved: Invalid argument
MV_RC=1 elapsed=0s
=== DONE RUN 2 ===

=== BEFORE/AFTER CONTRAST ===
BASELINE (#0, unpatched ext2fs.ko):
    mv S A/S_moved  ->  HANGS FOREVER (kernel thread R3, 100% CPU, SIGKILL-proof,
                         CPU time climbing 0:53 -> 1:39 -> 6:53 monotonically;
                         /tmp/df0824_mvstatus never written)
PATCHED (fixed ext2fs.ko, EXT2_CHECKPATH_MAXDEPTH=256):
    mv S A/S_moved  ->  returns EINVAL in 0s ("Invalid argument");
                         MV_RC=1; guest healthy; no stuck process

The fix closes the bug: the unbounded `..` walk in ext2_checkpath() now bails
with EINVAL after 256 iterations (well beyond any legitimate directory nesting
depth), breaking the A<->B cycle instead of looping forever.