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

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

Patch Review

**Verdict: Needs rework for locking issues.**

**Issue 1 — `filelist_mutex` held during reclaim (serious):**

`panthor_run_on_pfiles_of_tgid` holds `ptdev->base.filelist_mutex` for the entire duration of the callback:

```c
scoped_cond_guard(mutex_intr, return -EINTR, &ptdev->base.filelist_mutex) {
    list_for_each_entry(file, &ptdev->base.filelist, lhead) {
        ...
        func(file->driver_priv);  /* called with filelist_mutex held */
    }
}
```

`panthor_mmu_force_reclaim` calls `panthor_mmu_reclaim_priv_bos` which calls `drm_gem_lru_scan` → `panthor_gem_try_evict`, which acquires BO reservation locks and does actual page eviction (writeback to swap). Holding `filelist_mutex` throughout blocks all `drm_open`/`drm_close` on the device. On an embedded system with multiple GPU clients, this could cause significant stalls.

The fix would be to collect references to the relevant `panthor_file` objects under the mutex, then release the mutex before invoking the callbacks.

**Issue 2 — Missing xarray locking (bug):**

```c
xa_for_each(&pfile->vms->xa, i, vm) {
    if (!vm->reclaim.lru.count)
        continue;
    nr_to_scan += vm->reclaim.lru.count;
    list_move(&vm->reclaim.lru_node, &ptdev->reclaim.vms);
}
```

Existing code in panthor (e.g., the fdinfo stats path at `panthor_mmu.c:2081`) takes `xa_lock(&pfile->vms->xa)` before iterating. Here the iteration runs without `xa_lock`, racing with concurrent `xa_store`/`xa_erase` from VM create/destroy ioctls. A concurrent `panthor_vm_pool_destroy_vm` could erase and free a VM while this loop is accessing it.

**Issue 3 — No VM reference on the iterated VMs:**

Compare with `panthor_vm_pool_get_vm` which does `panthor_vm_get(xa_load(...))` under `xa_lock`. The force_reclaim code accesses `vm->reclaim.lru.count` and `vm->reclaim.lru_node` without a reference. If the VM is concurrently destroyed, these accesses are use-after-free.

**Issue 4 — TGID lookup could be simplified:**

```c
file_pid = rcu_dereference(file->pid);
task = pid_task(file_pid, PIDTYPE_TGID);
if (!task || task->tgid != tgid) {
```

Since `file->pid` is set to `task_tgid(current)` in `drm_file_alloc`, `pid_nr(file_pid)` already gives the TGID number. The task lookup is unnecessary — `pid_nr(file_pid) != tgid` would suffice and avoids touching the task struct.

**Issue 5 — PID namespace correctness:**

The user writes a TGID via sysfs, and the code compares it against `task->tgid` (which is the global namespace pid). If the writer is in a PID namespace, their view of the TGID won't match the global value. Using `pid_vnr()` or documenting this as init-namespace-only would be more correct.

**Issue 6 — Negative TGID accepted:**

`kstrtoint` allows negative values, and the code doesn't reject `tgid <= 0`. While the lookup would simply fail with `-ESRCH`, explicitly rejecting invalid TGIDs would be cleaner.

---
Generated by Claude Code Patch Reviewer