# DF-3162 — revoke(2) on a FIFO silently does nothing

## Root cause
`vrevoke()` forwards non-VCHR vnodes to `fdrevoke(vp, DTYPE_VNODE, cred)`
(sys/kern/vfs_subr.c:1450-1452).  But fifo file pointers are tagged
`f_type = DTYPE_FIFO` by `vop_stdopen()`
(sys/kern/vfs_default.c:1172-1175), and `fdrevoke`'s matcher requires
`info->data == fp->f_data && info->type == fp->f_type`
(sys/kern/kern_descrip.c:1999).  `DTYPE_VNODE (1) != DTYPE_FIFO (4)`
(sys/sys/file.h:125-128), so no fp is ever marked FREVOKED and no
descriptor is closed: `revoke(2)` on a fifo returns **success** while
every descriptor stays open and functional.

revoke(2)'s privilege gate passes for the fifo's owner
(sys/kern/vfs_syscalls.c:4741-4742), so this is reachable by an
unprivileged user on fifos they own.

## PoC
`revoke_fifo_noop.c` — mkfifo, open reader+writer, `revoke(path)` (as
owner), then push a byte through the descriptors.

## Build / run
    cc -O -Wall -o revoke_fifo_noop revoke_fifo_noop.c
    ./revoke_fifo_noop          # as any user; fifo is owned by the caller

## Expected output (bug present)
    fifo opened: rfd=3 wfd=4 (uid=1001)
    revoke(/tmp/df3162_fifo) returned 0 (owner is allowed to revoke)
    BUG-DF-3162: fds still functional after revoke(2) (data rfd<->wfd still flows)
    VERDICT: reproduced

## Expected output (fixed kernel)
    OK: write after revoke failed: EPIPE (or read side EBADF/EOF)