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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox