Claude review: drm/virtio: Extend blob UAPI with deferred-mapping hinting

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

Patch Review

**UAPI: Missing validation of unknown `blob_hints` bits**

In `verify_blob()`, `blob_flags` is validated against `VIRTGPU_BLOB_FLAG_USE_MASK` to reject unknown bits (line 448), but `blob_hints` is accepted unconditionally:

```c
params->blob_hints = rc_blob->blob_hints;
```

This violates the standard kernel UAPI convention: unknown flags/bits must be rejected so that userspace can probe for new features by checking for `-EINVAL`. Without this, old kernels will silently ignore future hint bits, and userspace cannot detect whether a hint is actually supported. A `blob_hints & ~DRM_VIRTGPU_BLOB_FLAG_HINT_DEFER_MAPPING` check returning `-EINVAL` is needed.

**Bug: `virtio_gpu_vram_map_deferred()` ignores the return value of `virtio_gpu_vram_map()`, causing potential indefinite hang**

```c
void virtio_gpu_vram_map_deferred(struct virtio_gpu_object_vram *vram)
{
	if (!(vram->base.blob_flags & VIRTGPU_BLOB_FLAG_USE_MAPPABLE))
		return;

	mutex_lock(&map_lock);
	if (!drm_mm_node_allocated(&vram->vram_node))
		virtio_gpu_vram_map(&vram->base);    /* return value ignored */
	mutex_unlock(&map_lock);
}
```

`virtio_gpu_vram_map()` can fail (e.g., `drm_mm_insert_node` fails when VRAM is exhausted, or `virtio_gpu_array_alloc` returns NULL). If it fails, no map command is sent to the host, so `map_state` stays at `STATE_INITIALIZING` (0, the kzalloc default). The caller in `virtio_gpu_vram_mmap()` then does:

```c
wait_event(vgdev->resp_wq, vram->map_state != STATE_INITIALIZING);
```

This will **block forever** because no response will ever arrive to change `map_state`. The function should return `int`, propagate the error, or at minimum set `vram->map_state = STATE_ERR` on failure so the wait_event unblocks and the mmap returns `-EINVAL`.

**dma-buf export path not handling deferred mapping**

`virtio_gpu_vram_map_dma_buf()` directly accesses `vram->vram_node.start` and `vram->vram_node.size` (virtgpu_vram.c:107-108):

```c
addr = dma_map_resource(dev, vram->vram_node.start,
			vram->vram_node.size, dir,
			DMA_ATTR_SKIP_CPU_SYNC);
```

If a BO was created with `DRM_VIRTGPU_BLOB_FLAG_HINT_DEFER_MAPPING`, the vram_node will not be allocated yet, and these fields will be zero/uninitialized. The dma-buf path needs to trigger the deferred mapping (and wait for completion) before accessing the node, or reject the export.

**Global static mutex is heavy-handed**

```c
static DEFINE_MUTEX(map_lock);
```

This serializes all deferred VRAM mappings across all virtio-gpu device instances in the system. A per-device or per-object lock would be more appropriate. Additionally, there's a locking inconsistency: `virtio_gpu_vram_free()` checks `drm_mm_node_allocated()` under `vgdev->host_visible_lock` (spinlock), while `virtio_gpu_vram_map_deferred()` checks it under this unrelated global mutex. While GEM refcounting should prevent races between free and deferred-map, the inconsistent locking protocol is fragile.

**UAPI naming inconsistency**

The existing flags in `struct drm_virtgpu_resource_create_blob` use the `VIRTGPU_BLOB_` prefix (e.g., `VIRTGPU_BLOB_FLAG_USE_MAPPABLE`), but the new hint uses `DRM_VIRTGPU_BLOB_FLAG_HINT_DEFER_MAPPING`. This breaks the naming convention within the same struct. Consider using `VIRTGPU_BLOB_HINT_DEFER_MAPPING` for consistency.

**Minor: `map_state` read without barrier**

In `virtio_gpu_vram_mmap()`:

```c
virtio_gpu_vram_map_deferred(vram);

if (vram->map_state == STATE_INITIALIZING)
    virtio_gpu_notify(vgdev);
```

The read of `map_state` here is outside any lock and has no memory barrier, while the write side (in `virtio_gpu_vq.c:1377`) is under `host_visible_lock`. The subsequent `wait_event` does a proper recheck, so this doesn't cause functional breakage — the worst case is a redundant `virtio_gpu_notify` call — but it's technically a data race.

**Summary of required changes:**
1. Add validation in `verify_blob()` to reject unknown `blob_hints` bits
2. Handle the return value of `virtio_gpu_vram_map()` in the deferred path to avoid hangs
3. Handle (or reject) deferred-mapping BOs in the dma-buf map path
4. Consider per-device locking instead of a global mutex
5. Fix the UAPI naming to match the existing convention

---
Generated by Claude Code Patch Reviewer