From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Re: [PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports Date: Tue, 05 May 2026 11:08:36 +1000 Message-ID: In-Reply-To: <3d8deeb15581b754e4c061d4c4a13657aa08bc3c.camel@ndufresne.ca> References: <3d8deeb15581b754e4c061d4c4a13657aa08bc3c.camel@ndufresne.ca> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: Re: [PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports Author: Nicolas Dufresne 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