From: Jonathan Marek <jonathan@marek.ca>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Andy Gross <agross@kernel.org>,
David Brown <david.brown@linaro.org>,
"open list:QUALCOMM VENUS VIDEO ACCELERATOR DRIVER"
<linux-media@vger.kernel.org>,
"open list:QUALCOMM VENUS VIDEO ACCELERATOR DRIVER"
<linux-arm-msm@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Revert "media: hfi_parser: don't trick gcc with a wrong expected size"
Date: Wed, 5 Jun 2019 17:27:38 -0400 [thread overview]
Message-ID: <c0a251c1-d36a-613b-4573-5939cdfc3ebe@marek.ca> (raw)
In-Reply-To: <20190605174044.65ac1e4a@coco.lan>
hfi_capabilities / hfi_profile_level_supported come from hardware so
there is no option to dynamically allocate, and using size [1] doesn't
cause any bug.
Your enclosed patch is wrong in a way because MAX_CAP_ENTRIES is not a
hardware limit but the size of the statically allocated array used by
the driver. I don't think there is any defined hardware limit, otherwise
the driver author would've defined it as they did with
HFI_MAX_PROFILE_COUNT.
A better solution (IMO) if you want to avoid these warnings is to remove
those memcpy() and work on the data[] / profile_level[] from the struct
directly:
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c
b/drivers/media/platform/qcom/venus/hfi_parser.c
index 2293d936e49c..ecaa336b2cb9 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -94,16 +94,12 @@ static void
parse_profile_level(struct venus_core *core, u32 codecs, u32 domain,
void *data)
{
struct hfi_profile_level_supported *pl = data;
- struct hfi_profile_level *proflevel = pl->profile_level;
- struct hfi_profile_level pl_arr[HFI_MAX_PROFILE_COUNT] = {};
if (pl->profile_count > HFI_MAX_PROFILE_COUNT)
return;
- memcpy(pl_arr, proflevel, pl->profile_count * sizeof(*proflevel));
-
for_each_codec(core->caps, ARRAY_SIZE(core->caps), codecs, domain,
- fill_profile_level, pl_arr, pl->profile_count);
+ fill_profile_level, pl->profile_level, pl->profile_count);
}
static void
@@ -119,17 +115,12 @@ static void
parse_caps(struct venus_core *core, u32 codecs, u32 domain, void *data)
{
struct hfi_capabilities *caps = data;
- struct hfi_capability *cap = caps->data;
- u32 num_caps = caps->num_capabilities;
- struct hfi_capability caps_arr[MAX_CAP_ENTRIES] = {};
- if (num_caps > MAX_CAP_ENTRIES)
+ if (caps->num_capabilities > MAX_CAP_ENTRIES)
return;
- memcpy(caps_arr, cap, num_caps * sizeof(*cap));
-
for_each_codec(core->caps, ARRAY_SIZE(core->caps), codecs, domain,
- fill_caps, caps_arr, num_caps);
+ fill_caps, caps->data, caps->num_capabilities);
}
static void fill_raw_fmts(struct venus_caps *cap, const void *fmts,
On 6/5/19 4:41 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Jun 2019 16:19:40 -0400
> Jonathan Marek <jonathan@marek.ca> escreveu:
>
>> This reverts commit ded716267196862809e5926072adc962a611a1e3.
>>
>> This change doesn't make any sense and breaks the driver.
>
> The fix is indeed wrong, but reverting is the wrong thing to do.
>
> The problem is that the driver is trying to write past the
> allocated area, as reported:
>
> drivers/media/platform/qcom/venus/hfi_parser.c:103 parse_profile_level() error: memcpy() 'proflevel' too small (8 vs 128)
> drivers/media/platform/qcom/venus/hfi_parser.c:129 parse_caps() error: memcpy() 'cap' too small (16 vs 512)
>
> If you check the memcpy() logic at the above lines, you'll see that
> hfi_capability.data may have up to 32 entries, and
> hfi_profile_level_supported.profile level can have up to it can be up
> to 16 entries.
>
> So, the buffer should either be dynamically allocated with the real
> size or we need something like the enclosed patch.
>
> Thanks,
> Mauro
>
> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
> index 7a3feb5cee00..06a84f266bcc 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -59,7 +59,6 @@ struct venus_format {
>
> #define MAX_PLANES 4
> #define MAX_FMT_ENTRIES 32
> -#define MAX_CAP_ENTRIES 32
> #define MAX_ALLOC_MODE_ENTRIES 16
> #define MAX_CODEC_NUM 32
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h b/drivers/media/platform/qcom/venus/hfi_helper.h
> index 34ea503a9842..ca8033381515 100644
> --- a/drivers/media/platform/qcom/venus/hfi_helper.h
> +++ b/drivers/media/platform/qcom/venus/hfi_helper.h
> @@ -560,6 +560,8 @@ struct hfi_bitrate {
> #define HFI_CAPABILITY_HIER_P_HYBRID_NUM_ENH_LAYERS 0x15
> #define HFI_CAPABILITY_MBS_PER_SECOND_POWERSAVE 0x16
>
> +#define MAX_CAP_ENTRIES 32
> +
> struct hfi_capability {
> u32 capability_type;
> u32 min;
> @@ -569,7 +571,7 @@ struct hfi_capability {
>
> struct hfi_capabilities {
> u32 num_capabilities;
> - struct hfi_capability *data;
> + struct hfi_capability data[MAX_CAP_ENTRIES];
> };
>
> #define HFI_DEBUG_MSG_LOW 0x01
> @@ -726,7 +728,7 @@ struct hfi_profile_level {
>
> struct hfi_profile_level_supported {
> u32 profile_count;
> - struct hfi_profile_level *profile_level;
> + struct hfi_profile_level profile_level[HFI_MAX_PROFILE_COUNT];
> };
>
> struct hfi_quality_vs_speed {
>
>
>
next prev parent reply other threads:[~2019-06-05 21:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 20:19 Jonathan Marek
2019-06-05 20:41 ` Mauro Carvalho Chehab
2019-06-05 21:27 ` Jonathan Marek [this message]
2019-06-06 20:57 ` Stanimir Varbanov
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=c0a251c1-d36a-613b-4573-5939cdfc3ebe@marek.ca \
--to=jonathan@marek.ca \
--cc=agross@kernel.org \
--cc=david.brown@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--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
all inboxes | Powered by JetHome®