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

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

Patch Review

**1. Clone for VMapOwned calls unwrap_unchecked**: 

```rust
impl<D: DriverObject, const SIZE: usize> Clone for VMapOwned<D, SIZE> {
    fn clone(&self) -> Self {
        unsafe { self.owner.owned_vmap().unwrap_unchecked() }
    }
}
```

The safety comment says "We have a successful vmap already, so this can't fail." This relies on the fact that `drm_gem_shmem_vmap_locked` uses a refcount (`vmap_use_count`) and will succeed if there's already an active vmap. This is true for the non-iomem path but should be documented more carefully — if the existing vmap was non-iomem, the cloned one will also be non-iomem (since it's the same cached mapping). The real risk is that between clone attempts the vmap could theoretically be released and re-acquired as iomem, but since we hold a reference (`self` exists), the refcount prevents that. The reasoning is sound but subtle.

**2. VMap::From<VMapRef> uses mem::forget**: 

```rust
impl<'a, D: DriverObject, const SIZE: usize> From<VMapRef<'a, D, SIZE>> for VMapOwned<D, SIZE> {
    fn from(value: VMapRef<'a, D, SIZE>) -> Self {
        let this = Self {
            addr: value.addr,
            owner: value.owner.into(),
        };
        mem::forget(value);
        this
    }
}
```

This is correct — the `mem::forget` prevents double-vunmap since we're transferring ownership of the mapping. Good pattern.

**3. No Send/Sync for VMapRef**: `Send` and `Sync` are only implemented for `VMapOwned`, not `VMapRef`. This is correct since `VMapRef` borrows from the object and the lifetime prevents sending across threads.

**4. Tests are well-structured**: The kunit tests verify compile-time size checking and basic I/O operations. The test for `vmap::<{ PAGE_SIZE + 200 }>().is_err()` is a good sanity check. The `vmap_io` test verifying byte-level reads within a u32 write is good for catching endianness assumptions — though the expected byte values (`0xFF` at all four positions) would be the same on both big and little endian for `0xFFFFFFFF`, so it doesn't actually test endianness. A value like `0xDEADBEEF` would be more revealing, but this is minor.

**5. ENOTSUPP for iomem**: The use of `ENOTSUPP` (which is the internal kernel variant, not `EOPNOTSUPP`) is fine for internal kernel use. The comment `// XXX: We don't currently support iomem allocations` appropriately flags this as a known limitation.

---
Generated by Claude Code Patch Reviewer