media: videobuf2-core: sanity checks for requests and qbuf
authorHans Verkuil <hverkuil-cisco@xs4all.nl>
Thu, 29 Jul 2021 13:36:27 +0000 (15:36 +0200)
committerMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Thu, 30 Sep 2021 08:07:38 +0000 (10:07 +0200)
The combination of supports_requests == 1 and min_buffers_needed > 0
is not allowed, WARN on that and return an error.

Also check that if vb2_core_qbuf() is called from req_queue, that it
doesn't return an error, unless it is -EIO.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
drivers/media/common/videobuf2/videobuf2-core.c

index 508ac29..38ce7c2 100644 (file)
@@ -1421,9 +1421,19 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
 static void vb2_req_queue(struct media_request_object *obj)
 {
        struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
+       int err;
 
        mutex_lock(vb->vb2_queue->lock);
-       vb2_core_qbuf(vb->vb2_queue, vb->index, NULL, NULL);
+       /*
+        * There is no method to propagate an error from vb2_core_qbuf(),
+        * so if this returns a non-0 value, then WARN.
+        *
+        * The only exception is -EIO which is returned if q->error is
+        * set. We just ignore that, and expect this will be caught the
+        * next time vb2_req_prepare() is called.
+        */
+       err = vb2_core_qbuf(vb->vb2_queue, vb->index, NULL, NULL);
+       WARN_ON_ONCE(err && err != -EIO);
        mutex_unlock(vb->vb2_queue->lock);
 }
 
@@ -2342,6 +2352,17 @@ int vb2_core_queue_init(struct vb2_queue *q)
        if (WARN_ON(q->requires_requests && !q->supports_requests))
                return -EINVAL;
 
+       /*
+        * This combination is not allowed since a non-zero value of
+        * q->min_buffers_needed can cause vb2_core_qbuf() to fail if
+        * it has to call start_streaming(), and the Request API expects
+        * that queueing a request (and thus queueing a buffer contained
+        * in that request) will always succeed. There is no method of
+        * propagating an error back to userspace.
+        */
+       if (WARN_ON(q->supports_requests && q->min_buffers_needed))
+               return -EINVAL;
+
        INIT_LIST_HEAD(&q->queued_list);
        INIT_LIST_HEAD(&q->done_list);
        spin_lock_init(&q->done_lock);