Claude review: drm/panthor: Support sparse mappings

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

Patch Review

This is the core patch. Several observations:

**Type truncation in `panthor_vm_map_sparse`:**

```c
u32 chunk_size = min(size - mapped, SZ_2M - (addr & (SZ_2M - 1)));
```

Both `size` and `mapped` are `u64`, and `SZ_2M - (addr & (SZ_2M - 1))` can be up to `SZ_2M` (0x200000), which fits in `u32`. However, `size - mapped` can be an arbitrary `u64`. The `min()` macro in the kernel will compute the minimum correctly (the result will always fit in u32 since it's at most SZ_2M), but `chunk_size` should be `u64` for type consistency and to avoid any compiler warnings about implicit narrowing. The `panthor_vm_map_pages` function takes `u64 size`, so this gets widened anyway, but declaring it `u32` is sloppy.

**Dummy BO reference management is correct.** The pool holds one reference, each VM takes its own reference in `panthor_vm_pool_create_vm`. The VM releases its reference in `panthor_vm_free`, and the pool releases its reference in `panthor_vm_pool_destroy`. The error path in `panthor_vm_pool_create_vm` (xa_alloc failure) calls `panthor_vm_put` which eventually reaches `panthor_vm_free` — the dummy ref is properly cleaned up.

**The v13 fix for UAF in `panthor_vm_pool_create`:** The error path calls `panthor_vm_pool_destroy(pfile)`, which will check `pfile->vms->dummy` before putting. Since `dummy` isn't assigned until after `panthor_dummy_bo_create` succeeds, the `if (pfile->vms->dummy)` guard in `panthor_vm_pool_destroy` is necessary and correct. Good.

**Validation in `panthor_vm_prepare_map_op_ctx`:** The check `if (is_sparse && (op->bo_handle || op->bo_offset))` correctly rejects sparse ops with user-supplied BO handles or offsets. The NOEXEC requirement is also enforced. Both are consistent with the uAPI documentation.

**`panthor_fix_sparse_map_offset`:** This function adjusts `op->gem.offset = op->va.addr & (SZ_2M - 1)` for sparse mappings, ensuring the cyclic mapping aligns correctly within the 2MiB dummy BO. It's called in `sm_step_map`, `sm_step_remap` (for both prev and next), and `remap_evicted_vma`. The comment on `sm_step_remap` says "op->remap.prev's BO offset is always the same as the unmap va's" — but then in the prev remap block, it explicitly calls `panthor_fix_sparse_map_offset(&map_op, unmap_vma->flags)` again, which is redundant but harmless for sparse and a no-op for non-sparse.

**`unmap_hugepage_align` sparse treatment:** For sparse mappings, the code always assumes THP (huge page) backing, unconditionally expanding the unmap region to 2MiB alignment. The comment explains this is a deliberate simplification. This is a reasonable tradeoff — the overhead of a wider unmap+remap is small compared to the complexity of checking actual page sizes for the cyclically-mapped dummy BO.

**`panthor_vm_get_bo_for_va` offset calculation:**

```c
*bo_offset = !(vma->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE) ?
    vma->base.gem.offset + (va - vma->base.va.addr) :
    va & (SZ_2M - 1);
```

This correctly maps the VA back into the 2MiB dummy BO for sparse VMAs.

**`panthor_vm_map_bo_range` guard:** The added `drm_WARN_ON` check prevents internal kernel callers from accidentally using the sparse flag, which is appropriate since sparse mappings are only intended for userspace-driven VM_BIND operations.

**Minor style nit:** The comment style on the sparse-specific checks in `panthor_vm_prepare_map_op_ctx` uses `/* ... */` in a way that's inconsistent — some multi-line comments use `/* first line\n * continuation */` while one uses `/* first line\n * continuation\n */`. This is cosmetic.

---
Generated by Claude Code Patch Reviewer