Both attached reproducers, on a GENERIC (INVARIANTS) amd64 bhyve VM:
main-n287675-95439b803fce both reproducers panic
+ this revision (n287676) no panic, mount path reported
panic: condition vp->v_type == VDIR || VN_IS_DOOMED(vp) not met
at sys/kern/vfs_cache.c:3547 (vn_fullpath_dir)
vn_fullpath_dir()
vn_fullpath_hardlink()
proc_get_binpath()
sysctl_kern_proc_pathname()
which matches the backtrace in the textdump on PR 282596. With the
revision applied both reproducers report the mount path, e.g.
"pathname = /tmp/filemount.iWdI2g.renamed/cover".
filemount_panic.sh is the shell version; filemount_panic.c is the same
sequence as bare syscalls: nmount(2) of a single-file nullfs mount,
execve(2) of the mount point, rename(2) of the containing directory,
then kern.proc.pathname.
The rename(2) is what makes this still reproduce on today's main. It
drops the covered file's namecache entry via cache_vop_rename(), so the
reverse walk has to fall back to vn_fullpath_dir(). Without it the
lock-free walk silently returns the doubled path instead, which is why
the reproducers posted earlier no longer panicked after 29d1a3248a6d.