Message ID | 20240229095611.6698-2-yunfei.dong@mediatek.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Sebastian Fricke |
Headers |
Received: from sv.mirrors.kernel.org ([139.178.88.99]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-6135-patchwork=linuxtv.org@vger.kernel.org>) id 1rfd9z-00009h-1q for patchwork@linuxtv.org; Thu, 29 Feb 2024 09:57:04 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D64A828B30E for <patchwork@linuxtv.org>; Thu, 29 Feb 2024 09:57:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A8D6063109; Thu, 29 Feb 2024 09:56:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="Zo9dDuHu" X-Original-To: linux-media@vger.kernel.org Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1287562801; Thu, 29 Feb 2024 09:56:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.244.123.138 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709200584; cv=none; b=unImOK2+uDtY4UYcCHvUWEKQFAzM1PK8IxWKMzmcskgLN9NYmgXSN9MxecWjTPghHkFmPDu20MAcMh96zrLewrPPwywxH9AXqO1/4SwjdipVTRNYLjnt50AJ99nxWmiucb+U1o7ppzkRkr3n0FKTerNROtwF7DRGPPoGfYe4HqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709200584; c=relaxed/simple; bh=Kuxb7Z7SxDymhUXCf/8OI233Gjndg1g669+lIXC5Gwg=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HOL8UFIE8vXcFylE+Ig1ZeYNuJ05CAUBOgXtklSQw5bYPoixBZwlk+rmy6z0fggL6etSfhllQmSJfJu70uV1yYiBUyILt4XhkNl7fP26FktL+pouKlIECDDo4xMp/C2LWPS/JJwL8b3ZH4JSU/ugK4jvaUrVFA0ZN+oAnFKI0xE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com; spf=pass smtp.mailfrom=mediatek.com; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b=Zo9dDuHu; arc=none smtp.client-ip=60.244.123.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mediatek.com X-UUID: c6d18096d6e811eeb8927bc1f75efef4-20240229 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=NSJvBf2MtjtGhjMO2/ZFmTYLI8qmp/2QaCoKqPV6uw8=; b=Zo9dDuHuECaL8Yegn9VKliddA9lYXyjYw4S+a/rV3ckzUAV4SvfhSYi86uS42expLvTfUcmnAKO09xyx55VY+XEKS0qiorBh1JuNzatBh4Ulij4r3rQjJuMpfThI5ii35LgXhcgTa1MUJFUQSnKy5SAuBY/ZOLfLrGTqpVwhO9o=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.37,REQID:5b0e5b89-0de6-49f0-9717-81229bd439bc,IP:0,U RL:0,TC:0,Content:-5,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:-5 X-CID-META: VersionHash:6f543d0,CLOUDID:6e18f380-4f93-4875-95e7-8c66ea833d57,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:0,File:nil,RT:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1, SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 0,NGT X-CID-BAS: 0,NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-UUID: c6d18096d6e811eeb8927bc1f75efef4-20240229 Received: from mtkmbs11n1.mediatek.inc [(172.21.101.185)] by mailgw01.mediatek.com (envelope-from <yunfei.dong@mediatek.com>) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1390350831; Thu, 29 Feb 2024 17:56:15 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs13n1.mediatek.inc (172.21.101.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Thu, 29 Feb 2024 17:56:13 +0800 Received: from mhfsdcap04.gcn.mediatek.inc (10.17.3.154) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Thu, 29 Feb 2024 17:56:13 +0800 From: Yunfei Dong <yunfei.dong@mediatek.com> To: =?utf-8?q?N=C3=ADcolas_F_=2E_R_=2E_A_=2E_Prado?= <nfraprado@collabora.com>, Nicolas Dufresne <nicolas.dufresne@collabora.com>, Hans Verkuil <hverkuil-cisco@xs4all.nl>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Benjamin Gaignard <benjamin.gaignard@collabora.com>, Nathan Hebert <nhebert@chromium.org> CC: Hsin-Yi Wang <hsinyi@chromium.org>, Fritz Koenig <frkoenig@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, Steve Cho <stevecho@chromium.org>, Yunfei Dong <yunfei.dong@mediatek.com>, <linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <Project_Global_Chrome_Upstream_Group@mediatek.com> Subject: [PATCH 1/3] media: mediatek: vcodec: fix h264 multi statless decoder smatch warning Date: Thu, 29 Feb 2024 17:56:09 +0800 Message-ID: <20240229095611.6698-2-yunfei.dong@mediatek.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240229095611.6698-1-yunfei.dong@mediatek.com> References: <20240229095611.6698-1-yunfei.dong@mediatek.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-MTK: N X-LSpam-Score: -3.0 (---) X-LSpam-Report: No, score=-3.0 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_MED=-2.3,SPF_HELO_NONE=0.001,SPF_PASS=-0.001,UNPARSEABLE_RELAY=0.001 autolearn=unavailable autolearn_force=no |
Series |
media: mediatek: vcodec: fix vcodec smatch warning
|
|
Commit Message
Yunfei Dong
Feb. 29, 2024, 9:56 a.m. UTC
Fix smatch static checker warning for vdec_h264_req_multi_if.c.
Leading to kernel crash when fb is NULL.
Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Comments
Il 29/02/24 10:56, Yunfei Dong ha scritto: > Fix smatch static checker warning for vdec_h264_req_multi_if.c. > Leading to kernel crash when fb is NULL. > > Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder") > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > --- > .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c > index 0e741e0dc8ba..ab8e708e0df1 100644 > --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c > +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c > @@ -724,11 +724,16 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs > return vpu_dec_reset(vpu); > > fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx); > + if (!fb) { > + mtk_vdec_err(inst->ctx, "fb buffer is NULL"); > + return -EBUSY; > + } > + > src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer); > dst_buf_info = container_of(fb, struct mtk_video_dec_buf, frame_buffer); > > - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0; > - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0; You're changing the behavior here, can you please explain why this change is valid into the commit description? Thanks, Angelo > + y_fb_dma = (u64)fb->base_y.dma_addr; > + c_fb_dma = (u64)fb->base_c.dma_addr; > mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx c_dma=%llx", > inst->ctx->decoded_frame_cnt, y_fb_dma, c_fb_dma); >
Hi AngeloGioacchino, Thanks for your reviewing. On Tue, 2024-04-02 at 11:50 +0200, AngeloGioacchino Del Regno wrote: > Il 29/02/24 10:56, Yunfei Dong ha scritto: > > Fix smatch static checker warning for vdec_h264_req_multi_if.c. > > Leading to kernel crash when fb is NULL. > > > > Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder") > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > > --- > > .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 > > +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req > > _multi_if.c > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req > > _multi_if.c > > index 0e741e0dc8ba..ab8e708e0df1 100644 > > --- > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req > > _multi_if.c > > +++ > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req > > _multi_if.c > > @@ -724,11 +724,16 @@ static int vdec_h264_slice_single_decode(void > > *h_vdec, struct mtk_vcodec_mem *bs > > return vpu_dec_reset(vpu); > > > > fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx); > > + if (!fb) { > > + mtk_vdec_err(inst->ctx, "fb buffer is NULL"); > > + return -EBUSY; > > + } > > + > > src_buf_info = container_of(bs, struct mtk_video_dec_buf, > > bs_buffer); > > dst_buf_info = container_of(fb, struct mtk_video_dec_buf, > > frame_buffer); > > > > - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0; > > - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0; > > You're changing the behavior here, can you please explain why this > change is valid > into the commit description? > The driver already add the condition to check whether fb is NULL at the front, no need these two lines again. > Thanks, > Angelo > Best Regards, Yunfei Dong > > + y_fb_dma = (u64)fb->base_y.dma_addr; > > + c_fb_dma = (u64)fb->base_c.dma_addr; > > mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx > > c_dma=%llx", > > inst->ctx->decoded_frame_cnt, y_fb_dma, > > c_fb_dma); > > > > >
Hi, W dniu 3.04.2024 o 05:45, Yunfei Dong (董云飞) pisze: > Hi AngeloGioacchino, > > Thanks for your reviewing. > On Tue, 2024-04-02 at 11:50 +0200, AngeloGioacchino Del Regno wrote: >> Il 29/02/24 10:56, Yunfei Dong ha scritto: >>> Fix smatch static checker warning for vdec_h264_req_multi_if.c. >>> Leading to kernel crash when fb is NULL. >>> >>> Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder") >>> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> >>> --- >>> .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 >>> +++++++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git >>> a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req >>> _multi_if.c >>> b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req >>> _multi_if.c >>> index 0e741e0dc8ba..ab8e708e0df1 100644 >>> --- >>> a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req >>> _multi_if.c >>> +++ >>> b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req >>> _multi_if.c >>> @@ -724,11 +724,16 @@ static int vdec_h264_slice_single_decode(void >>> *h_vdec, struct mtk_vcodec_mem *bs >>> return vpu_dec_reset(vpu); >>> >>> fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx); >>> + if (!fb) { >>> + mtk_vdec_err(inst->ctx, "fb buffer is NULL"); >>> + return -EBUSY; >>> + } >>> + >>> src_buf_info = container_of(bs, struct mtk_video_dec_buf, >>> bs_buffer); >>> dst_buf_info = container_of(fb, struct mtk_video_dec_buf, >>> frame_buffer); >>> >>> - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0; >>> - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0; >> >> You're changing the behavior here, can you please explain why this >> change is valid >> into the commit description? >> > The driver already add the condition to check whether fb is NULL at the > front, no need these two lines again. > Maybe Angelo refers to the function never returning -EBUSY before? While at it, if fb is a kind of a buffer, why not -ENOMEM when get_cap_buffer() fails? Regards, Andrzej >> Thanks, >> Angelo >> > Best Regards, > Yunfei Dong >>> + y_fb_dma = (u64)fb->base_y.dma_addr; >>> + c_fb_dma = (u64)fb->base_c.dma_addr; >>> mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx >>> c_dma=%llx", >>> inst->ctx->decoded_frame_cnt, y_fb_dma, >>> c_fb_dma); >>> >> >> >>
Hi Andrzej, Thanks for your help to review this patch. On Wed, 2024-05-29 at 15:14 +0200, Andrzej Pietrasiewicz wrote: > Hi, > > W dniu 3.04.2024 o 05:45, Yunfei Dong (董云飞) pisze: > > Hi AngeloGioacchino, > > > > Thanks for your reviewing. > > On Tue, 2024-04-02 at 11:50 +0200, AngeloGioacchino Del Regno > > wrote: > > > Il 29/02/24 10:56, Yunfei Dong ha scritto: > > > > Fix smatch static checker warning for vdec_h264_req_multi_if.c. > > > > Leading to kernel crash when fb is NULL. > > > > > > > > Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 > > > > decoder") > > > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > > > > --- > > > > .../vcodec/decoder/vdec/vdec_h264_req_multi_if.c | 9 > > > > +++++++-- > > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > > diff --git > > > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264 > > > > _req > > > > _multi_if.c > > > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264 > > > > _req > > > > _multi_if.c > > > > index 0e741e0dc8ba..ab8e708e0df1 100644 > > > > --- > > > > a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264 > > > > _req > > > > _multi_if.c > > > > +++ > > > > b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264 > > > > _req > > > > _multi_if.c > > > > @@ -724,11 +724,16 @@ static int > > > > vdec_h264_slice_single_decode(void > > > > *h_vdec, struct mtk_vcodec_mem *bs > > > > return vpu_dec_reset(vpu); > > > > > > > > fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst- > > > > >ctx); > > > > + if (!fb) { > > > > + mtk_vdec_err(inst->ctx, "fb buffer is NULL"); > > > > + return -EBUSY; > > > > + } > > > > + > > > > src_buf_info = container_of(bs, struct > > > > mtk_video_dec_buf, > > > > bs_buffer); > > > > dst_buf_info = container_of(fb, struct > > > > mtk_video_dec_buf, > > > > frame_buffer); > > > > > > > > - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0; > > > > - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0; > > > > > > You're changing the behavior here, can you please explain why > > > this > > > change is valid > > > into the commit description? > > > > > > > The driver already add the condition to check whether fb is NULL at > > the > > front, no need these two lines again. > > > > Maybe Angelo refers to the function never returning -EBUSY before? > While at it, if fb is a kind of a buffer, why not -ENOMEM > when get_cap_buffer() fails? > Looks change the return value from EBUSY to ENOMEM much more reasonable. > Regards, > > Andrzej > Best Regards, Yunfei Dong > > > Thanks, > > > Angelo > > > > > > > Best Regards, > > Yunfei Dong > > > > + y_fb_dma = (u64)fb->base_y.dma_addr; > > > > + c_fb_dma = (u64)fb->base_c.dma_addr; > > > > mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx > > > > c_dma=%llx", > > > > inst->ctx->decoded_frame_cnt, y_fb_dma, > > > > c_fb_dma); > > > > > > > > > > > > > > >
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c index 0e741e0dc8ba..ab8e708e0df1 100644 --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c @@ -724,11 +724,16 @@ static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs return vpu_dec_reset(vpu); fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx); + if (!fb) { + mtk_vdec_err(inst->ctx, "fb buffer is NULL"); + return -EBUSY; + } + src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer); dst_buf_info = container_of(fb, struct mtk_video_dec_buf, frame_buffer); - y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0; - c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0; + y_fb_dma = (u64)fb->base_y.dma_addr; + c_fb_dma = (u64)fb->base_c.dma_addr; mtk_vdec_debug(inst->ctx, "[h264-dec] [%d] y_dma=%llx c_dma=%llx", inst->ctx->decoded_frame_cnt, y_fb_dma, c_fb_dma);