Claude review: pvr: acquire vm_ctx->lock before mapping memory to GPU VM

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

Patch Review

**Bug: double `mutex_unlock` on the success path**

After the patch, `pvr_vm_map()` looks like this (lines 750–764):

```c
	mutex_lock(&vm_ctx->lock);          // line 750
	err = drm_gpuvm_exec_lock(&vm_exec);
	if (err)
		goto err_cleanup;

	err = pvr_vm_bind_op_exec(&bind_op);

	drm_gpuvm_exec_unlock(&vm_exec);
	mutex_unlock(&vm_ctx->lock);        // line 758 — first unlock

err_cleanup:
	pvr_vm_bind_op_fini(&bind_op);
	mutex_unlock(&vm_ctx->lock);        // line 762 — SECOND unlock!

	return err;
```

On the **success path** (no error), execution flows:
1. `mutex_lock` at line 750
2. `mutex_unlock` at line 758 (after `drm_gpuvm_exec_unlock`)
3. Falls through to `err_cleanup`
4. `mutex_unlock` at line 762 — **double unlock**, which is undefined behavior on a non-recursive mutex and will trigger `DEBUG_LOCKS_WARN_ON` with lockdep enabled.

On the **error path** (`drm_gpuvm_exec_lock` fails), it correctly jumps to `err_cleanup` and unlocks once.

**Fix:** The success path needs to skip the second unlock. The cleanest approaches would be either:

1. Replace the `mutex_unlock` + fall-through with a `goto` past `err_cleanup`:
```c
	drm_gpuvm_exec_unlock(&vm_exec);

err_cleanup:
	pvr_vm_bind_op_fini(&bind_op);
	mutex_unlock(&vm_ctx->lock);

	return err;
```
This mirrors the existing pattern for `drm_gpuvm_exec_unlock` where it unlocks before the label but the `_fini` is shared. Just move the single `mutex_unlock` to the shared cleanup block.

2. Or, use `goto` to skip the second unlock on the success path.

**Minor observation on the commit message:**
- "NULL deference" should be "NULL dereference" (typo).
- "all occurences" should be "all occurrences".
- The commit message claims "all occurrences of `drm_gpuva_find*()` is already guarded by `vm_ctx->lock`," which is accurate based on the code at lines 865–867 and 891–898. The rationale is sound — the issue is purely in the implementation.

**Verdict:** The motivation is correct and the fix is needed, but this patch **must not be applied as-is** due to the double-unlock bug. It needs a v2.

---
Generated by Claude Code Patch Reviewer