Claude review: Re: [PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports

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

Overall Series Review

Subject: Re: [PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports
Author: Nicolas Dufresne <nicolas@ndufresne.ca>
Patches: 6
Reviewed: 2026-05-05T11:08:36.888563

---

This RFC series adds opt-in dma_resv write-fence support to videobuf2-core so that V4L2 producers can populate a real implicit-sync fence on exported dmabufs, signaled when `vb2_buffer_done()` fires. The motivation is sound -- Wayland compositors and other dmabuf consumers currently see only stub fences from V4L2 producers, which is a real gap in the implicit sync contract. The implementation approach (opt-in per-driver, single helper call) is clean and incremental.

However, there are several correctness issues that need to be addressed before this can move beyond RFC:

1. **Fence leak on requeue path**: If `vb2_buffer_done(vb, VB2_BUF_STATE_QUEUED)` is called (requeue), the fence is never signaled, and a subsequent `vb2_buffer_attach_release_fence()` call on the same buffer will hit the `WARN_ON` and fail, leaving consumers stuck on an unsignaled fence forever.
2. **No cleanup in `__vb2_queue_cancel`**: The cancel path does not signal/put outstanding release fences for buffers that were queued but not ACTIVE.
3. **Fences attached to both OUTPUT and CAPTURE queues**: For M2M devices, `DMA_RESV_USAGE_WRITE` on OUTPUT buffers is semantically incorrect -- the device reads from OUTPUT buffers, it doesn't write to them.
4. **Wasteful allocation when no planes have dmabufs**: The fence is allocated even if no planes have a `dbuf`, creating a fence that is attached to nothing.

The locking model is correct: `dma_resv_lock()` from `buf_queue` (process context) is safe, and `dma_fence_signal()` from `vb2_buffer_done()` (potentially IRQ context) is safe.

---

---
Generated by Claude Code Patch Reviewer