Hi Hans,
On Mon, Nov 19, 2018 at 8:09 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>
> Calling VIDIOC_DQBUF can release the core serialization lock pointed to
> by vb2_queue->lock if it has to wait for a new buffer to arrive.
>
> However, if userspace dup()ped the video device filehandle, then it is
> possible to read or call DQBUF from two filehandles at the same time.
>
> It is also possible to call REQBUFS from one filehandle while the other
> is waiting for a buffer. This will remove all the buffers and reallocate
> new ones. Removing all the buffers isn't the problem here (that's already
> handled correctly by DQBUF), but the reallocating part is: DQBUF isn't
> aware that the buffers have changed.
>
> This is fixed by setting a flag whenever the lock is released while waiting
> for a buffer to arrive. And checking the flag where needed so we can return
> -EBUSY.
>
> Signed-off-by: Hans Verkuil <hverkuil@xxxxxxxxx>
> Reported-by: syzbot+4180ff9ca6810b06c1e9@xxxxxxxxxxxxxxxxxxxxxxxxx
> ---
> .../media/common/videobuf2/videobuf2-core.c | 22 +++++++++++++++++++
> include/media/videobuf2-core.h | 1 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
> index 975ff5669f72..f7e7e633bcd7 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -672,6 +672,11 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
> return -EBUSY;
> }
>
> + if (q->waiting_in_dqbuf && *count) {
> + dprintk(1, "another dup()ped fd is waiting for a buffer\n");
Actually, couldn't it also happen with the same FD just another thread?
That said, it's just a debugging message, so feel free to just add
Reviewed-by: Tomasz Figa <tfiga@xxxxxxxxxxxx>
Best regards,
Tomasz
