From: Dan Carpenter <dan.carpenter@oracle.com>
To: a.hajda@samsung.com
Cc: linux-media@vger.kernel.org
Subject: [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue
Date: Thu, 4 Apr 2019 18:42:16 +0300 [thread overview]
Message-ID: <20190404154216.GA24343@kadam> (raw)
Hello Andrzej Hajda,
The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
identify last buffers in decoder capture queue" from Oct 7, 2015,
leads to the following static checker warning:
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c:664 vidioc_dqbuf()
warn: uncapped user index 'ctx->dst_bufs[buf->index]'
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
642 static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
643 {
644 const struct v4l2_event ev = {
645 .type = V4L2_EVENT_EOS
646 };
647 struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
648 int ret;
649
650 if (ctx->state == MFCINST_ERROR) {
651 mfc_err_limited("Call on DQBUF after unrecoverable error\n");
652 return -EIO;
653 }
654
655 switch (buf->type) {
656 case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
657 return vb2_dqbuf(&ctx->vq_src, buf, file->f_flags & O_NONBLOCK);
658 case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
659 ret = vb2_dqbuf(&ctx->vq_dst, buf, file->f_flags & O_NONBLOCK);
660 if (ret)
661 return ret;
662
663 if (ctx->state == MFCINST_FINISHED &&
--> 664 (ctx->dst_bufs[buf->index].flags & MFC_BUF_FLAG_EOS))
^^^^^^^^^^
Smatch is saying that this isn't capped. The truth is that v4l2 code is
a bit complicated for Smatch, but in this case I can't see where
"buf->index" does get capped. I would have expected it to be capped in
check_array_args() where we check "buf->length" but it's not.
I've been going through these warnings really carefully in the past
couple weeks trying to fix false positives so let me know what I'm
missing and I will update the check. Even if I have to manually muck
in the DB.
665 v4l2_event_queue_fh(&ctx->fh, &ev);
666 return 0;
667 default:
668 return -EINVAL;
669 }
670 }
regards,
dan carpenter
next reply other threads:[~2019-04-04 15:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190404154231epcas4p11c6ce6ab44d5b61c66e246fab78972e9@epcas4p1.samsung.com>
2019-04-04 15:42 ` Dan Carpenter [this message]
2019-04-05 10:02 ` [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue Andrzej Hajda
2019-04-05 11:33 ` Dan Carpenter
[not found] <CGME20180123083259epcas3p1fb9a8b4e4ad34eb245fca67d4204cba4@epcas3p1.samsung.com>
2018-01-23 8:32 ` Dan Carpenter
2018-01-25 9:58 ` Andrzej Hajda
2018-01-25 10:14 ` Hans Verkuil
2018-01-25 12:25 ` Dan Carpenter
2018-01-25 12:31 ` Hans Verkuil
2018-01-25 13:10 ` Dan Carpenter
2018-01-25 12:46 ` Andrzej Hajda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190404154216.GA24343@kadam \
--to=dan.carpenter@oracle.com \
--cc=a.hajda@samsung.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.