Re: [PATCH] staging: most: video: add comments to mutex and spinlock definitions

[Dan Carpenter]

On Sat, Sep 12, 2026 at 12:21:01AM +0500, Muhammad Israr wrote:
> On Thu, Sep 12, 2026 at 12:19:00AM +0000, Dan Carpenter wrote:
> > It's supposed to but it is buggy...  What prevents multiple
> > threads from reading comp_vdev_read() at the same time?
> > I prefer to keep the warning around until someone fixes the
> > code.
> 
> Thanks for pointing this out!
> I traced through comp_vdev_read(): list_lock (the spinlock --
> the mutex field in this struct is unrelated, it's only vdev->lock
> used for V4L2 ioctl serialization) is only actually held around
> the final list_del() in the read loop. data_ready() and
> get_top_mbo(), both called earlier in the same function, read
> pending_mbos with no lock held at all. comp_rx_data() (the
> rx_completion producer) does take list_lock correctly around its
> list_add_tail(), but that only protects against whatever happens
> to be holding list_lock at that instant  which today is just
> the list_del() call. So nothing stops two threads from both being
> inside comp_vdev_read() concurrently and reading/deciding on the
> same list state unprotected, which is what you were asking about.

Imagine one thread is calling get_top_mbo() which reads:

	list_first_entry(&mdev->pending_mbos, struct mbo, list);

but the other thread is calling:

	list_del(&mbo->list);

It's a race condition.  We can't delete two at the time, fine.
But we also should be trying to read from one while it's being
deleted.

regards,
dan carpenter