vkernel64: sys_umtx_sleep() calls blocking uservtophys() inside a critical section — LWKT lock-protocol violation

Summary

On the vkernel64 platform, kern_umtx.c:216 re-resolves the physical address via uservtophys() INSIDE the crit_enter() begun at :199. The vkernel64 implementation calls vm_fault_page(..., VM_FAULT_NORMAL, ...), which blocks on non-resident/busy/COW pages. Blocking inside an LWKT critical section violates the core protocol ('This code can't block ... or bad things will happen') and can deadlock or trip the switch-from-critical-section assertions. The pc64 implementation is a lockless PTE read and is safe; only vkernel64 diverges. Unprivileged process inside a vkernel64 kernel triggers repeated blocking page faults from within a critical section (e.g. fork()/mprotect() COW break racing between the initial translation at :147 and the in-crit re-check at :216) under memory pressure → vkernel panic/deadlock — availability only, vkernel64 deployments only. Not Phase-V verified (pc64 guest; nested vkernel disproportionate to a Low vkernel-only DoS). Fix: make vkernel64's uservtophys a non-blocking advisory translation matching pc64 semantics (row sketch).

Timeline

• 2026-09-02 Discovered during pass-2 audit of kern_umtx.c (GLM 5.3).