pmap_inval.c discards every madvise()/vmspace_mcontrol() return value — the vkernel's sole memory-revocation primitive fails silently, leaving stale (possibly writable) host PTEs with no diagnostic

Summary

All six invalidation wrappers issue the host-syscall flush and ignore its result - but the host pmap_remove behind MADV_INVAL is the ONLY mechanism enforcing guest-kernel memory revocation (mprotect write-removal, munmap, COW demotion) against guest userland: a failure leaves the guest kernel believing memory is unmapped/write-protected while host CPUs keep a live translation. Proven unreachable today (guest/host VM_MAX_USER_ADDRESS bit-identical and 2MB-aligned so EINVAL checks pass; ENOENT only during vmspace destroy when no live ptes remain) - Info hardening; any future failure would be a silent write-protect/unmap bypass with zero diagnostics. retry-EINTR + panic-on-failure fix proposed. Negative results carried: no DF-5420 twin (no mask state machine - this shim delegates synchronously to the host), no DF-5586 analog on these paths (signal deferral gated), VPTE_PS never set so pmap_inval_pde is dead code (pmap_clean_pde unimplemented with #if 0 callers - latent trap only).