From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Irui Wang <irui.wang@mediatek.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
nicolas.dufresne@collabora.com
Cc: Project_Global_Chrome_Upstream_Group@mediatek.com,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Yunfei Dong <yunfei.dong@mediatek.com>,
Longfei Wang <longfei.wang@mediatek.com>
Subject: Re: [PATCH] media: mediatek: encoder: memset encoder structure data
Date: Tue, 15 Jul 2025 15:26:22 +0200 [thread overview]
Message-ID: <ddcd26ad-1bf1-4d14-b341-3c0e1e56cbf3@collabora.com> (raw)
In-Reply-To: <20250715081547.18076-1-irui.wang@mediatek.com>
Il 15/07/25 10:15, Irui Wang ha scritto:
> Utilized memset to set all bytes of encoder structure to zero,
> this prevents any undefined behavior due to uninitialized use.
>
> Signed-off-by: Irui Wang <irui.wang@mediatek.com>
This commit needs a Fixes tag, as you're fixing something important here.
Also, please clarify what is this undefined behavior that you've seen and
what problem are you trying to resolve by zeroing all those mem locations.
There's also more feedback, check below...
> ---
> .../media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
> index a01dc25a7699..ecac1aec7215 100644
> --- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
> @@ -886,6 +886,7 @@ static int vb2ops_venc_start_streaming(struct vb2_queue *q, unsigned int count)
> return 0;
> }
>
> + memset(¶m, 0, sizeof(param));
Have you considered doing, instead...
struct venc_enc_param param = { 0 }; ?
> mtk_venc_set_param(ctx, ¶m);
> ret = venc_if_set_param(ctx, VENC_SET_PARAM_ENC, ¶m);
> if (ret) {
> @@ -1021,12 +1022,14 @@ static int mtk_venc_encode_header(void *priv)
> struct mtk_vcodec_mem bs_buf;
> struct venc_done_result enc_result;
struct venc_done_result enc_result = { 0 };
>
> + memset(&enc_result, 0, sizeof(enc_result));
> dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
> if (!dst_buf) {
> mtk_v4l2_venc_dbg(1, ctx, "No dst buffer");
> return -EINVAL;
> }
>
> + memset(&bs_buf, 0, sizeof(bs_buf));
> bs_buf.va = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
> bs_buf.dma_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
> bs_buf.size = (size_t)dst_buf->vb2_buf.planes[0].length;
> @@ -1143,6 +1146,7 @@ static void mtk_venc_worker(struct work_struct *work)
> struct venc_done_result enc_result;
> int ret, i;
>
> + memset(&enc_result, 0, sizeof(enc_result));
You should probably move this to before the first usage, instead.
> /* check dst_buf, dst_buf may be removed in device_run
> * to stored encdoe header so we need check dst_buf and
> * call job_finish here to prevent recursion
> @@ -1175,6 +1179,7 @@ static void mtk_venc_worker(struct work_struct *work)
> frm_buf.fb_addr[i].size =
> (size_t)src_buf->vb2_buf.planes[i].length;
> }
> + memset(&bs_buf, 0, sizeof(bs_buf));
here it's fine to use memset, as there are multiple ways out before actually using
bs_buf.
Cheers,
Angelo
> bs_buf.va = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
> bs_buf.dma_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
> bs_buf.size = (size_t)dst_buf->vb2_buf.planes[0].length;
next prev parent reply other threads:[~2025-07-15 13:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 8:15 Irui Wang
2025-07-15 13:26 ` AngeloGioacchino Del Regno [this message]
2025-07-16 2:46 ` Irui Wang (王瑞)
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=ddcd26ad-1bf1-4d14-b341-3c0e1e56cbf3@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=irui.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=longfei.wang@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=yunfei.dong@mediatek.com \
/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®