Claude review: accel/qaic: Protect perf stats BO state with bo->lock

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

Patch Review

**Race analysis: Correct.** The detach path in `qaic_detach_slice_bo_ioctl()` (line 1908) acquires `bo->lock` before calling `detach_slice_bo()`, which calls `qaic_unprepare_bo()` (sets `bo->dbc = NULL` at line 931) and `qaic_init_bo(bo, true)` (sets `bo->sliced = false` at line 685). Without the lock in the perf stats ioctl, a concurrent detach could:
1. Clear `bo->sliced` after the `!bo->sliced` check passes, leading to stale reads of `bo->perf_stats`.
2. Set `bo->dbc = NULL` after the `bo->sliced` check but before `bo->dbc->id` is read, causing a NULL pointer dereference.

**Locking scope: Correct.** The lock is held from before the `bo->sliced` check through the copy of all perf stats fields into `ent[i]`, which is exactly the critical section.

**Error path cleanup: Correct.** The old code had `drm_gem_object_put(obj)` duplicated in each error branch and on the success path. The new code consolidates into a single `drm_gem_object_put(obj)` at the `put_obj` label, with the `if (ret) goto free_ent` check happening after both unlock and put. This is cleaner and matches the pattern used in `qaic_detach_slice_bo_ioctl()`.

**Minor note on `mutex_lock_interruptible`:** Using `mutex_lock_interruptible` is consistent with how `bo->lock` is acquired throughout the file (lines 1034, 1225, 1908). This is the right choice for an ioctl path -- it allows the syscall to be interrupted by signals rather than blocking indefinitely.

**Fixes tag:** Points at commit `4ddf4ddfceb4` which added the `bo->dbc` validation check but didn't add the lock. This is accurate.

**No issues found.** The patch is correct and ready to merge.

---
Generated by Claude Code Patch Reviewer