Claude review: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups

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

Patch Review

**Status: Good**

This patch fixes a resource leak in `v3d_rewrite_csd_job_wg_counts_from_indirect()`. Looking at the existing code in the kernel tree (`v3d_sched.c:400-406`):

```c
v3d_get_bo_vaddr(bo);
v3d_get_bo_vaddr(indirect);

wg_counts = (uint32_t *)(bo->vaddr + indirect_csd->offset);

if (wg_counts[0] == 0 || wg_counts[1] == 0 || wg_counts[2] == 0)
    return;
```

The bare `return` at line 406 skips the cleanup at lines 431-432 (`v3d_put_bo_vaddr(indirect)` / `v3d_put_bo_vaddr(bo)`), leaking both mappings. The fix correctly replaces `return` with `goto unmap_bo`, which jumps to the cleanup path:

```c
if (wg_counts[0] == 0 || wg_counts[1] == 0 || wg_counts[2] == 0)
    goto unmap_bo;
```

```c
unmap_bo:
	v3d_put_bo_vaddr(indirect);
	v3d_put_bo_vaddr(bo);
```

The label placement is correct — it sits right before both `v3d_put_bo_vaddr` calls, matching the acquisition order (bo, indirect acquired; indirect, bo released). The label name `unmap_bo` is slightly ambiguous since it unmaps both BOs, but this is a minor style nit that doesn't affect correctness.

One observation: when the zero-workgroup path is taken, `args->cfg[0..4]` are left untouched — they retain whatever userspace submitted. This is fine because patch 2 ensures the CSD job is never submitted to hardware when counts are zero.

---
Generated by Claude Code Patch Reviewer