Claude review: drm/panthor: Support sparse mappings

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

Patch Review

This is the main patch. Several issues:

**1. Memory leak in `panthor_vm_pool_create` error path:**

```c
+	pfile->vms->dummy = panthor_dummy_bo_create(pfile->ptdev);
+	if (IS_ERR(pfile->vms->dummy))
+		return PTR_ERR(pfile->vms->dummy);
```

If `panthor_dummy_bo_create` fails, the function returns an error without freeing `pfile->vms` or destroying the xarray initialized two lines above. The caller (`panthor_open`) goes to `err_free_file` which frees `pfile` but not `pfile->vms`. This leaks the `panthor_vm_pool` allocation and the xarray. Additionally, `pfile->vms` is left pointing to memory with `dummy` set to an ERR_PTR, which would crash if `panthor_vm_pool_destroy` were ever called on it (it does `drm_gem_object_put(&pfile->vms->dummy->base)`). The error path should clean up and set `pfile->vms = NULL`.

**2. Wrong address passed to `iova_mapped_as_huge_page` for `op->next` (regression):**

In `unmap_hugepage_align`, the `op->next` branch was changed from:
```c
-	    iova_mapped_as_huge_page(op->next, unmap_end - 1)) {
+	    (iova_mapped_as_huge_page(op->next, *unmap_start, is_sparse))) {
```

For the non-sparse case, the `addr` parameter is used to compute:
```c
bo_offset = addr - op->va.addr + op->gem.offset;
```

The original code passed `unmap_end - 1` (last byte of the unmapped region), which is just before `op->next->va.addr`. The replacement `*unmap_start` is the *beginning* of the unmap region, which is well before `op->next->va.addr`, causing `addr - op->va.addr` to underflow (unsigned). For sparse, `bo_offset` is forced to 0 so the bug doesn't manifest, but this is a regression for non-sparse remap operations. The fix should pass `unmap_end - 1` for non-sparse and `*unmap_start` (or any value) for sparse.

**3. `panthor_vm_map_sparse` — minor observation:**

```c
+	while (size > 0) {
+		u64 next_size = min(size, sg_dma_len(sgt->sgl));
```

This always uses `sgt->sgl` (the first SG entry). If the dummy BO's pages are not physically contiguous, the first SG entry might be small (4KiB), meaning the entire sparse range maps to the same physical page repeatedly. This is functionally correct (sparse semantics say reads are undefined) but could be slow for large ranges. The comment about the 2MiB dummy BO in `panthor_dummy_bo_create` acknowledges this uncertainty — worth noting but not blocking.

**4. Remap `size > 0` guards:**

The patch adds `&& size > 0` checks in the remap prev/next branches:
```c
-		if (!unmap_vma->evicted) {
+		if (!unmap_vma->evicted && size > 0) {
```

This seems defensive — it's not clear when `size` could be zero in normal operation. If this is guarding against edge cases in the hugepage-aligned unmap calculations for sparse mappings, a brief comment explaining when this can happen would be helpful.

**5. The design choice of per-file-context dummy BOs is well-motivated** — the commit message clearly explains the information-leak concern. The VM holding its own reference to `pool->dummy` to survive past file context destruction is correct.

---
Generated by Claude Code Patch Reviewer