From: Dan Carpenter <dan.carpenter@oracle.com>
To: kbuild@lists.01.org, Dikshita Agarwal <dikshita@codeaurora.org>
Cc: lkp@intel.com, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org,
Stanimir Varbanov <stanimir.varbanov@linaro.org>
Subject: drivers/media/platform/qcom/venus/helpers.c:627 venus_helper_get_bufreq() error: we previously assumed 'req' could be null (see line 623)
Date: Mon, 7 Feb 2022 11:15:49 +0300 [thread overview]
Message-ID: <202202062034.T1pUQtL9-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 90c9e950c0def5c354b4a6154a2ddda3e5f214ac
commit: 16545aa3dee5a01f3f42aa566a051096c87f4b6f media: venus: Set buffer to FW based on FW min count requirement.
config: microblaze-randconfig-m031-20220206 (https://download.01.org/0day-ci/archive/20220206/202202062034.T1pUQtL9-lkp@intel.com/config)
compiler: microblaze-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/media/platform/qcom/venus/helpers.c:627 venus_helper_get_bufreq() error: we previously assumed 'req' could be null (see line 623)
vim +/req +627 drivers/media/platform/qcom/venus/helpers.c
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 615 int venus_helper_get_bufreq(struct venus_inst *inst, u32 type,
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 616 struct hfi_buffer_requirements *req)
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 617 {
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 618 u32 ptype = HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 619 union hfi_get_property hprop;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 620 unsigned int i;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 621 int ret;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 622
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 @623 if (req)
Check for NULL
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 624 memset(req, 0, sizeof(*req));
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 625
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 626 if (type == HFI_BUFFER_OUTPUT || type == HFI_BUFFER_OUTPUT2)
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 @627 req->count_min = inst->fw_min_cnt;
Unchecked dereference
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 628
7371093f983d35d Stanimir Varbanov 2020-08-26 629 ret = platform_get_bufreq(inst, type, req);
I looked at this in linux-next from Friday and I don't think
platform_get_bufreq() can succeed with a NULL "req"...
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 630 if (!ret) {
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 631 if (type == HFI_BUFFER_OUTPUT || type == HFI_BUFFER_OUTPUT2)
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 632 inst->fw_min_cnt = req->count_min;
Unchecked
7371093f983d35d Stanimir Varbanov 2020-08-26 633 return 0;
16545aa3dee5a01 Dikshita Agarwal 2021-08-10 634 }
7371093f983d35d Stanimir Varbanov 2020-08-26 635
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 636 ret = hfi_session_get_property(inst, ptype, &hprop);
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 637 if (ret)
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 638 return ret;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 639
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 640 ret = -EINVAL;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 641
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 642 for (i = 0; i < HFI_BUFFER_TYPE_MAX; i++) {
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 643 if (hprop.bufreq[i].type != type)
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 644 continue;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 645
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 646 if (req)
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 647 memcpy(req, &hprop.bufreq[i], sizeof(*req));
Another NULL check
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 648 ret = 0;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 649 break;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 650 }
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 651
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 652 return ret;
af2c3834c8ca7cc Stanimir Varbanov 2017-06-15 653 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
next reply other threads:[~2022-02-07 8:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 8:15 Dan Carpenter [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-03-15 9:09 drivers/media/platform/qcom/venus/helpers.c:627 venus_helper_get_bufreq() error: we previously assumed 'req' could be null (see line 623) Dan Carpenter
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=202202062034.T1pUQtL9-lkp@intel.com \
--to=dan.carpenter@oracle.com \
--cc=dikshita@codeaurora.org \
--cc=kbuild-all@lists.01.org \
--cc=kbuild@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mchehab@kernel.org \
--cc=stanimir.varbanov@linaro.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