Claude review: rust: drm: gem: Add vmap functions to shmem bindings

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

Patch Review

Good patch overall with solid kunit tests. A few issues:

**Incorrect safety comment in `raw_vmap`:**

```rust
// SAFETY: The call to drm_gem_shmem_vunmap_locked succeeded above, so we are guaranteed
// that map is properly initialized.
let map = unsafe { map.assume_init() };
```

This should say `drm_gem_shmem_vmap_locked`, not `drm_gem_shmem_vunmap_locked`. Copy-paste error.

**`unwrap_unchecked` in `VMap::clone` is risky:**

```rust
impl<D: DriverObject, const SIZE: usize> Clone for VMap<D, SIZE> {
    fn clone(&self) -> Self {
        // SAFETY: We have a successful vmap already, so this can't fail
        unsafe { self.owner.owned_vmap().unwrap_unchecked() }
    }
}
```

While subsequent `drm_gem_shmem_vmap_locked` calls just bump a refcount when a vmap already exists (making failure practically impossible), this is still an `unsafe` `unwrap_unchecked` on a `Result` from an operation that goes through FFI and lock acquisition. If the vmap refcount implementation ever changes, this becomes UB instead of a panic. The same applies to `VMapRef::clone`. Consider whether a plain `unwrap()` (with a `// This cannot fail because...` comment) would be acceptable here, to get a panic instead of UB in the unexpected case.

**Send/Sync safety comments say "send across threads" for both:**

```rust
// SAFETY: addr is guaranteed to be valid and accessible for the lifetime of VMap, ensuring its
// safe to send across threads.
unsafe impl<D: DriverObject, const SIZE: usize> Send for VMap<D, SIZE> {}
// SAFETY: addr is guaranteed to be valid and accessible for the lifetime of VMap, ensuring its
// safe to send across threads.
unsafe impl<D: DriverObject, const SIZE: usize> Sync for VMap<D, SIZE> {}
```

The Sync comment should justify shared-reference safety (e.g., "safe to share references across threads"), not "send across threads". Minor nit.

**The kunit tests are good** — they verify compile-time size validation, basic I/O read/write, and the byte-level view of a u32 write. The test infrastructure is minimal and well-structured. One observation: the `vmap_io` test assumes little-endian byte ordering (`0xFFFFFFFF` → four `0xFF` bytes), which is true on most test platforms but could be noted.

---
Generated by Claude Code Patch Reviewer