tmpfs_alloc_vp KKASSERT(!TMPFS_VNODE_DOOMED) at subr.c:402 is an unguarded race window: NFS fhtovp lookups on an unlinked file during inactive's DOOMED..reclaim interval panic INVARIANTS kernels

Summary

tmpfs_inactive's tn_links==0 path sets tn_vpstate = TMPFS_VNODE_DOOMED (vnops:1799), releases the node lock, then runs tmpfs_truncate(vp, 0) - which for a large unlinked tmpfs file destroys millions of pages and can run for a long while - before vrecycle and tmpfs_reclaim finally store tn_vnode = NULL (vnops:1853). tmpfs_fhtovp (vfsops:451-462) scans tm_nodes_used by tn_id/tn_gen with no tn_links/DOOMED check and calls tmpfs_alloc_vp; any such caller taking the node lock inside that window sees node->tn_vnode != NULL (:395) and immediately trips KKASSERT((tn_vpstate & DOOMED) == 0) at :402 - panic on INVARIANTS/DEBUG builds. Name-based lookups cannot reach the window (links==0 means no dirent, namecache invalidated) - the only reachable racer is an NFS fh lookup on a root-exported tmpfs (unusual setup). Remote unauth NFS client with a stale fh hammering lookups while the server reclaims the unlinked file panics the INVARIANTS kernel - local DoS. Production kernels unaffected (assert compiled out; vhold/vget blocks on the vnode lock held through VOP_INACTIVE; list scan TMPFS_LOCK-serialized vs LIST_REMOVE - no UAF). Same assert family as DF-0779 but distinct site (fhtovp vs readdir cookie) and fix. Fix: handle the doomed-but-not-reclaimed vnode (return ENOENT + vx_put) and/or make fhtovp skip DOOMED/links==0 nodes in the scan.