From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: vfio/pci: Permanently revoke a DMABUF on request
Date: Thu, 28 May 2026 12:28:53 +1000
Message-ID: <review-patch8-20260527102319.100128-9-mattev@meta.com>
In-Reply-To: <20260527102319.100128-9-mattev@meta.com>
References: <20260527102319.100128-1-mattev@meta.com> <20260527102319.100128-9-mattev@meta.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

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