Claude review: drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock

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

Patch Review

**Verdict: Mostly good, minor observation.**

The fix adds `mutex_lock(&bo->madv_lock)` around the `bo->madv` check to prevent a data race with `DRM_IOCTL_VC4_GEM_MADVISE`.

```c
+mutex_lock(&bo->madv_lock);
 if (bo->madv != VC4_MADV_WILLNEED) {
     ...
+    mutex_unlock(&bo->madv_lock);
     return -EINVAL;
 }
+mutex_unlock(&bo->madv_lock);
 
 return drm_gem_dma_mmap(&bo->base, vma);
```

There is a TOCTOU window here: `madv` could change between dropping the lock and calling `drm_gem_dma_mmap()`. However, this is a pre-existing design pattern in the driver — the same TOCTOU exists in other madv-checking paths, and the comment in `vc4_save_hang_state` acknowledges that BO consistency "cannot be guaranteed" when userspace acts concurrently. The fix is consistent with how the rest of the driver handles this, and closes the data race on the read itself, which is the actual bug (unsynchronized access to a shared variable).

No blocking issues.

---

---
Generated by Claude Code Patch Reviewer