Skip to content

use vb2 queue lock for waits #58

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
grawis wants to merge 1 commit into
base: master
Choose a base branch
from
Open

use vb2 queue lock for waits #58

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 0 additions & 14 deletions videobuf.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,18 +103,6 @@ static void vcam_stop_streaming(struct vb2_queue *vb2_q)
spin_unlock_irqrestore(&dev->out_q_slock, flags);
}

static void vcam_outbuf_lock(struct vb2_queue *vq)
{
struct vcam_device *dev = vb2_get_drv_priv(vq);
mutex_lock(&dev->vcam_mutex);
}

static void vcam_outbuf_unlock(struct vb2_queue *vq)
{
struct vcam_device *dev = vb2_get_drv_priv(vq);
mutex_unlock(&dev->vcam_mutex);
}

static int vcam_buf_init(struct vb2_buffer *vb)
{
struct vcam_out_buffer *buf =
Expand All @@ -138,8 +126,6 @@ static const struct vb2_ops vcam_vb2_ops = {
.buf_queue = vcam_out_buffer_queue,
.start_streaming = vcam_start_streaming,
.stop_streaming = vcam_stop_streaming,
.wait_prepare = vcam_outbuf_unlock,

@cubic-dev-ai cubic-dev-ai Bot Aug 24, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: On kernels before ~6.6/6.7 (which lack the vb2 behavior added in upstream commit 88785982 where NULL wait_prepare/wait_finish auto-unlock q->lock), deleting these callbacks makes the blocking DQBUF wait hold vcam_mutex for its whole duration. Since the same mutex is vdev->lock, a thread blocked in DQBUF keeps the device lock, stalling concurrent STREAMOFF/QBUF/REQBUFS from other fds. The driver still targets old kernels via its version guards (6.8 and 4.17), so guard the removal: keep the two helper functions and restore the assignments for pre-6.6/6.7 kernels.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At videobuf.c, line 141:

<comment>On kernels before ~6.6/6.7 (which lack the vb2 behavior added in upstream commit 88785982 where NULL wait_prepare/wait_finish auto-unlock q->lock), deleting these callbacks makes the blocking DQBUF wait hold `vcam_mutex` for its whole duration. Since the same mutex is `vdev->lock`, a thread blocked in DQBUF keeps the device lock, stalling concurrent STREAMOFF/QBUF/REQBUFS from other fds. The driver still targets old kernels via its version guards (6.8 and 4.17), so guard the removal: keep the two helper functions and restore the assignments for pre-6.6/6.7 kernels.</comment>

<file context>
@@ -103,18 +103,6 @@ static void vcam_stop_streaming(struct vb2_queue *vb2_q)
     spin_unlock_irqrestore(&dev->out_q_slock, flags);
 }
 
-static void vcam_outbuf_lock(struct vb2_queue *vq)
-{
-    struct vcam_device *dev = vb2_get_drv_priv(vq);
-    mutex_lock(&dev->vcam_mutex);
-}
-
</file context>

.wait_finish = vcam_outbuf_lock,
.buf_init = vcam_buf_init,
.buf_cleanup = vcam_buf_cleanup,
};
Expand Down