Claude review: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings

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

Patch Review

**Bug analysis:**

In `host1x_bo_clear_cached_mappings()` (bus.c, around line 1010), the loop body does:

```c
cache = mapping->cache;          // line 1011: save cache pointer
if (WARN_ON(!cache))             // line 1012: NULL guard
    continue;

mutex_lock(&mapping->cache->lock);    // line 1015: dereferences mapping->cache
WARN_ON(kref_read(&mapping->ref) != 1);
__host1x_bo_unpin(&mapping->ref);     // line 1017: drops last ref → frees mapping
mutex_unlock(&mapping->cache->lock);  // line 1018: USE-AFTER-FREE
```

The call chain is: `__host1x_bo_unpin()` → `mapping->bo->ops->unpin(mapping)` → e.g. `tegra_bo_unpin()` which calls `kfree(map)`. After that, `mapping` is freed memory, so `mapping->cache->lock` on line 1018 is a use-after-free.

**Fix correctness:**

The fix simply replaces `mapping->cache->lock` with `cache->lock` in both the `mutex_lock` and `mutex_unlock` calls. This is safe because:

1. `cache` is assigned from `mapping->cache` *before* the unpin (line 1011)
2. The cache object outlives the mapping — it's owned by the host1x device, not the mapping
3. The `list_for_each_entry_safe` macro already saved `tmp` for safe iteration after the mapping is freed

**Nits:** None. The commit message is clear, properly credits the reporter with `Reported-by` and `Closes` tags, and the diff is minimal.

**Note on `WARN_ON(kref_read(&mapping->ref) != 1)`** (line 1016, untouched by this patch): This accesses `mapping->ref` *before* the unpin, so it's fine. Just worth noting for anyone reading along — the access ordering is correct.

Reviewed-by worthy as-is.

---
Generated by Claude Code Patch Reviewer