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: rust: gpuvm: add GpuVmCore::sm_map()
Date: Sun, 12 Apr 2026 11:16:42 +1000
Message-ID: <review-patch5-20260409-gpuvm-rust-v6-5-b16e6ada7261@google.com>
In-Reply-To: <20260409-gpuvm-rust-v6-5-b16e6ada7261@google.com>
References: <20260409-gpuvm-rust-v6-0-b16e6ada7261@google.com> <20260409-gpuvm-rust-v6-5-b16e6ada7261@google.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 the mapping operation: `OpMapRequest`, `OpMap`, `OpMapped`, `SmMapData`, and wires up `sm_step_map`.

**Observations:**

1. **`SmMapData` is `#[repr(C)]` with `sm_data: SmData` as first field**: This allows casting `*mut SmMapData` to `*mut SmData` in the unmap/remap callbacks, which receive the same private pointer. The `#[repr(C)]` ensures the layout. This is the same pattern used in C code where a struct extends another by embedding it as the first member. Correct.

2. **`sm_map` checks `vm_bo.gpuvm() != &**self`**: This is a runtime check (v6 addition) ensuring the VM-BO belongs to this GPUVM:
   ```rust
   if req.vm_bo.gpuvm() != &**self {
       return Err(EINVAL);
   }
   ```
   This uses pointer equality (from the `PartialEq` impl on `GpuVm<T>`). Good defensive check.

3. **`OpMap::insert` -- gpuva_link under lock**: The code correctly acquires the GEM lock before calling `drm_gpuva_link`:
   ```rust
   let _gpuva_guard = self.vm_bo().lock_gpuva();
   unsafe { bindings::drm_gpuva_link(va, self.vm_bo.as_raw()) };
   ```
   The guard is dropped implicitly at end of `insert()`. Correct.

4. **`sm_step_map` callback accesses `data()` through `p.sm_data.gpuvm`**: The callback calls `p.sm_data.gpuvm.data().sm_step_map(...)` which gives mutable access to the driver data through `UniqueRefGpuVm::data()`. This is correct since `SmData` holds `&mut UniqueRefGpuVm<T>`.

5. **Safety comment update for `sm_step_unmap`/`sm_step_remap`**: The safety comments are updated to reflect that these can now be called from both `sm_map` and `sm_unmap` with either `SmMapData` or `SmData`. The cast to `SmData` works for both because `SmMapData` has `SmData` as its first field with `#[repr(C)]`. Correct.

6. **`OpMapRequest` fields are public**: `addr`, `range`, `gem_offset`, `vm_bo`, and `context` are all `pub`. This is fine for a request struct -- drivers construct it directly.

**Summary of issues found:**

- **Minor bug/robustness**: In `obtain()` (patch 2), `dma_resv_lock()` return value is unchecked. While unlikely to fail with NULL ctx, it's not zero-cost to verify.
- **Potential leak**: In `OpRemap::remap` (patch 4), if both `prev` and `next` are `None` (shouldn't happen per C invariants), one `GpuVaAlloc` is silently leaked. A `debug_assert!` would catch this.
- **Nit**: The `// OVERFLOW:` comment in `va_range()` (patch 1) is slightly misleading -- it says "won't fail" but should say "won't overflow" since `Range<u64>` construction can't fail.

Overall this is high-quality work with careful attention to Rust safety invariants, lifetime enforcement, and correct integration with the C GPUVM API.

---
Generated by Claude Code Patch Reviewer