Claude review: drm/panthor: Add explicit memory claim sysfs knob

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

Patch Review

**Verdict: Needs rework, same locking issues plus error handling gaps.**

**Issue 1 — Same `filelist_mutex` + xarray locking issues as patch 3.**

`panthor_mmu_force_claim` is also called via `panthor_run_on_pfiles_of_tgid`, so all the locking concerns from patch 3 apply. Additionally, `drm_gpuvm_validate` allocates memory and does page I/O (swapping pages in from disk), making the `filelist_mutex` hold time potentially very long.

**Issue 2 — Missing xarray locking and VM references:**

```c
xa_for_each(&pfile->vms->xa, i, vm) {
    struct dma_resv *resv = drm_gpuvm_resv(&vm->base);
    dma_resv_lock(resv, NULL);
    ret = drm_gpuvm_validate(&vm->base, NULL);
    ...
    dma_resv_unlock(resv);
}
```

Same as patch 3: no `xa_lock`, no VM reference. A concurrent VM destroy could free the VM (and its resv) between the `xa_for_each` yielding the entry and `dma_resv_lock`.

**Issue 3 — Errors silently swallowed:**

`panthor_mmu_force_claim` has return type `void`, so `mem_claim_store` has no way to know if the swap-in failed. The sysfs documentation lists error codes like `-EINVAL` and `-EPERM`, but doesn't mention that the actual claim operation could silently fail. If `drm_gpuvm_validate` fails (e.g., due to OOM), userspace gets a success return code despite the memory not being paged in. This should either return an error or the function signature should be changed to propagate the first failure.

**Issue 4 — `dma_resv_lock(resv, NULL)` without deadlock avoidance:**

Using `NULL` ticket means no deadlock avoidance with other `ww_mutex` users. If the sysfs write races with a GPU submission that's acquiring the same resv locks through `drm_exec`, you could get an `-EDEADLK` that isn't handled. Consider using `dma_resv_lock_interruptible` at minimum.

**Issue 5 — Asymmetric privilege requirements:**

`mem_reclaim` allows a process to reclaim its own memory without `CAP_SYS_RESOURCE`, but `mem_claim` always requires `CAP_SYS_RESOURCE` even for self-claim. The documentation mentions this, but the asymmetry seems unnecessary — if a process can reclaim its own memory, why can't it claim it back? The commit message says this is intentional but doesn't explain the rationale.

---
Generated by Claude Code Patch Reviewer