Claude review: vfio/pci: Permanently revoke a DMABUF on request

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

Adds three-state revocation (OK/TEMP_REVOKED/PERM_REVOKED) and a new `VFIO_DEVICE_PCI_DMABUF_REVOKE` ioctl.

**Ioctl number**: Uses `VFIO_BASE + 22` which is confirmed available.

**Security check in `vfio_pci_dma_buf_revoke`**:
```c
+	if (dmabuf->ops != &vfio_pci_dmabuf_ops || priv->vdev != vdev) {
```
Checking `dmabuf->ops` prevents accepting arbitrary dmabufs. Good. The `priv->vdev != vdev` check prevents cross-device revocation. The comment about racing cleanup on a different vdev is well-reasoned.

**The `__vfio_pci_dma_buf_revoke` function**: The early-return logic for state transitions is clear:
```c
+	if ((priv->status == VFIO_PCI_DMABUF_PERM_REVOKED) ||
+	    (priv->status == VFIO_PCI_DMABUF_OK && !revoked) ||
+	    (priv->status == VFIO_PCI_DMABUF_TEMP_REVOKED && revoked && !permanently)) {
+		return;
+	}
```
The third condition (temp-revoked and requesting non-permanent revoke) correctly avoids redundant work. TEMP->PERM upgrade skips the invalidation path since the buffer is already gone. Sound.

**Missing `flags` field question**: The author asks whether a `flags` field should be added to `struct vfio_pci_dmabuf_revoke`. Given the `argsz` pattern already allows extension, I'd say no -- add it when needed. UAPI extensibility is already handled.

---
Generated by Claude Code Patch Reviewer