Message ID | 20230523162515.993862-1-benjamin.gaignard@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2285655vqo; Tue, 23 May 2023 09:58:35 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ68xn/bADxc1Bz0VImGlTCFqV5ua/1Ee38W5LlzH1++zJgTt/lo1FMXAhaQFg3hHnEoBJ7z X-Received: by 2002:a05:6a21:32a9:b0:ff:b9c4:a0aa with SMTP id yt41-20020a056a2132a900b000ffb9c4a0aamr17433148pzb.48.1684861114763; Tue, 23 May 2023 09:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684861114; cv=none; d=google.com; s=arc-20160816; b=Nbf3Daxzer7K644Rawh0XNxf8GPmEjFcfwa7hO1DKmcQPFulsftKoTwBdNLTUpFo3E MSh0HLMP+VW4l/HBS05tgb5yxexDCAW1A4ILBomEYPVIVfaWttQaZ2wt6D1VTFH0aFxc nHKJhYSm68lVxDC0cBJPBoUsDR0dKceU1DNUiuLsknZpG7cQF6va9kLFeTxMogiVPNLa 5mco2WcO30rrXW4ArxI+RyDeTaNwaLKERot5BlfOLHvLEU74rAToBLRQfS2kgOSOF0Xq Ki9Nw6soIMpIHHuu336hieYS02BgyMmy6/W4F6IDIvcrH53h96QNwqjrEJL5vYQqqn0W o+mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=HMqoOc11QEtjv9Gy9VLpe+tUPN0zZYtQVE/8ub4WEZg=; b=RMWWCnyM13IOAYIwgRzshwjLayAdo9ZYMogibaEm0RjcjHu24s9DXBfpRL7lovIY8T vDN570B1/ldI9UZ/tfqEzggGyBeH12ZIih4uHVsL8nkvdfqb/MO5gbeLPYsPyoSC8m2D spkxlVDm8SRXEZKv0CzOYC8Xj2tdpdKnh4vN/p9cEFv+qcxEsHfTlKaRHvjMKKo5Jl0d fuyfqOO34NFxIf6YSrjd3dtxK1n6YBtOfFgMY4VbIAi0Jd4y/8+J75u52NfNeneseKHf z4qHb7Li6ZHaCIsUMAFNYwdSPaKQJTFb4kdPj+pECCVkBfJDPaXDkZdR8p8pfjAG3rnm m3hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Sjc4Xq4A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m13-20020a63710d000000b0053ef547263csi974761pgc.398.2023.05.23.09.58.20; Tue, 23 May 2023 09:58:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Sjc4Xq4A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237017AbjEWQZb (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Tue, 23 May 2023 12:25:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233067AbjEWQZ3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 23 May 2023 12:25:29 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE373C2; Tue, 23 May 2023 09:25:24 -0700 (PDT) Received: from benjamin-XPS-13-9310.. (unknown [IPv6:2a01:e0a:120:3210:1ba:3e91:de16:9b34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: benjamin.gaignard) by madras.collabora.co.uk (Postfix) with ESMTPSA id CFFC56605961; Tue, 23 May 2023 17:25:22 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1684859123; bh=m0wdRLijBXDpapk6u3bXRwyWKtwK52v854JhKYzO1nY=; h=From:To:Cc:Subject:Date:From; b=Sjc4Xq4ABljQOpIT49MZaaPtLrwgnBcr6oDj8CHt+k7Lhj2kdV3uHLCPoNtziCzTu rec4ISSSxD8WNs2hJMFigTXAt2D2M2iH+E1jgxTDFAPBrMKDheBGgAMDDUXmt8TxUP yAIxDPZBwgGkZQrmfM1TELJkhvnSNDohXPmre6mGbBouxQBh17/992/yzaFiB1GoRw 9H+avykPJeQS5hgDoZyBOX+0+apYSA+oHFdB/qHBDgBiNu11BPAzNmN7Ws1ICJ5fSg GTQMk6hYEvAeXUklumgZCWnQGRBlXHttBYy7dbR7iMVT6uWol39BG2crC0codYNsIZ HK4Kti7Ps9sUg== From: Benjamin Gaignard <benjamin.gaignard@collabora.com> To: ezequiel@vanguardiasur.com.ar, nicolas.dufresne@collabora.com, p.zabel@pengutronix.de, mchehab@kernel.org, m.szyprowski@samsung.com, m.tretter@pengutronix.de, didi.debian@cknow.org Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, kernel@collabora.com, hverkuil-cisco@xs4all.nl, kernel@pengutronix.de, regressions@lists.linux.dev, Benjamin Gaignard <benjamin.gaignard@collabora.com> Subject: [PATCH] media: verisilicon: Additional fix for the crash when opening the driver Date: Tue, 23 May 2023 18:25:15 +0200 Message-Id: <20230523162515.993862-1-benjamin.gaignard@collabora.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766703401495339576?= X-GMAIL-MSGID: =?utf-8?q?1766704928130476295?= |
Series |
media: verisilicon: Additional fix for the crash when opening the driver
|
|
Commit Message
Benjamin Gaignard
May 23, 2023, 4:25 p.m. UTC
This fixes the following issue observed on Odroid-M1 board:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
Mem abort info:
...
Modules linked in: crct10dif_ce hantro_vpu snd_soc_simple_card snd_soc_simple_card_utils v4l2_vp9 v4l2_h264 rockchip_saradc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rtc_rk808 videobuf2_v4l2 industrialio_triggered_buffer rockchip_thermal dwmac_rk stmmac_platform stmmac videodev kfifo_buf display_connector videobuf2_common pcs_xpcs mc rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi drm_display_helper panfrost drm_shmem_helper gpu_sched ip_tables x_tables ipv6
CPU: 3 PID: 176 Comm: v4l_id Not tainted 6.3.0-rc7-next-20230420 #13481
Hardware name: Hardkernel ODROID-M1 (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : hantro_try_fmt+0xa0/0x278 [hantro_vpu]
lr : hantro_try_fmt+0x94/0x278 [hantro_vpu]
...
Call trace:
hantro_try_fmt+0xa0/0x278 [hantro_vpu]
hantro_set_fmt_out+0x3c/0x298 [hantro_vpu]
hantro_reset_raw_fmt+0x98/0x128 [hantro_vpu]
hantro_set_fmt_cap+0x240/0x254 [hantro_vpu]
hantro_reset_encoded_fmt+0x94/0xcc [hantro_vpu]
hantro_reset_fmts+0x18/0x38 [hantro_vpu]
hantro_open+0xd4/0x20c [hantro_vpu]
v4l2_open+0x80/0x120 [videodev]
chrdev_open+0xc0/0x22c
do_dentry_open+0x13c/0x48c
vfs_open+0x2c/0x38
path_openat+0x550/0x934
do_filp_open+0x80/0x12c
do_sys_openat2+0xb4/0x168
__arm64_sys_openat+0x64/0xac
invoke_syscall+0x48/0x114
el0_svc_common+0x100/0x120
do_el0_svc+0x3c/0xa8
el0_svc+0x40/0xa8
el0t_64_sync_handler+0xb8/0xbc
el0t_64_sync+0x190/0x194
Code: 97fc8a7f f940aa80 52864a61 72a686c1 (b9400800)
---[ end trace 0000000000000000 ]---
Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions")
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
---
drivers/media/platform/verisilicon/hantro_v4l2.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
Le 23/05/2023 à 18:28, Ezequiel Garcia a écrit : > Hi Benjamin, > > Thanks for the patch. > > On Tue, May 23, 2023 at 1:25 PM Benjamin Gaignard > <benjamin.gaignard@collabora.com> wrote: >> This fixes the following issue observed on Odroid-M1 board: >> >> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 > What pointer is NULL? ctx->src_fmt ? yes ctx->vpu_src_fmt pointer was NULL when probing the encoder. > >> Mem abort info: >> ... >> Modules linked in: crct10dif_ce hantro_vpu snd_soc_simple_card snd_soc_simple_card_utils v4l2_vp9 v4l2_h264 rockchip_saradc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rtc_rk808 videobuf2_v4l2 industrialio_triggered_buffer rockchip_thermal dwmac_rk stmmac_platform stmmac videodev kfifo_buf display_connector videobuf2_common pcs_xpcs mc rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi drm_display_helper panfrost drm_shmem_helper gpu_sched ip_tables x_tables ipv6 >> CPU: 3 PID: 176 Comm: v4l_id Not tainted 6.3.0-rc7-next-20230420 #13481 >> Hardware name: Hardkernel ODROID-M1 (DT) >> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) >> pc : hantro_try_fmt+0xa0/0x278 [hantro_vpu] >> lr : hantro_try_fmt+0x94/0x278 [hantro_vpu] >> ... >> Call trace: >> hantro_try_fmt+0xa0/0x278 [hantro_vpu] >> hantro_set_fmt_out+0x3c/0x298 [hantro_vpu] >> hantro_reset_raw_fmt+0x98/0x128 [hantro_vpu] >> hantro_set_fmt_cap+0x240/0x254 [hantro_vpu] >> hantro_reset_encoded_fmt+0x94/0xcc [hantro_vpu] >> hantro_reset_fmts+0x18/0x38 [hantro_vpu] >> hantro_open+0xd4/0x20c [hantro_vpu] >> v4l2_open+0x80/0x120 [videodev] >> chrdev_open+0xc0/0x22c >> do_dentry_open+0x13c/0x48c >> vfs_open+0x2c/0x38 >> path_openat+0x550/0x934 >> do_filp_open+0x80/0x12c >> do_sys_openat2+0xb4/0x168 >> __arm64_sys_openat+0x64/0xac >> invoke_syscall+0x48/0x114 >> el0_svc_common+0x100/0x120 >> do_el0_svc+0x3c/0xa8 >> el0_svc+0x40/0xa8 >> el0t_64_sync_handler+0xb8/0xbc >> el0t_64_sync+0x190/0x194 >> Code: 97fc8a7f f940aa80 52864a61 72a686c1 (b9400800) >> ---[ end trace 0000000000000000 ]--- >> >> Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions") >> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> >> --- >> drivers/media/platform/verisilicon/hantro_v4l2.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c >> index 835518534e3b..61cfaaf4e927 100644 >> --- a/drivers/media/platform/verisilicon/hantro_v4l2.c >> +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c >> @@ -397,10 +397,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth) >> if (!raw_vpu_fmt) >> return -EINVAL; >> >> - if (ctx->is_encoder) >> + if (ctx->is_encoder) { >> encoded_fmt = &ctx->dst_fmt; >> - else >> + ctx->vpu_src_fmt = raw_vpu_fmt; >> + } else { >> encoded_fmt = &ctx->src_fmt; >> + } >> >> hantro_reset_fmt(&raw_fmt, raw_vpu_fmt); >> raw_fmt.width = encoded_fmt->width; >> -- >> 2.34.1 >>
On Tue, 23 May 2023 18:36:09 +0200, Benjamin Gaignard wrote: > > Le 23/05/2023 à 18:25, Benjamin Gaignard a écrit : > > This fixes the following issue observed on Odroid-M1 board: > > > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 > > Mem abort info: > > ... > > Modules linked in: crct10dif_ce hantro_vpu snd_soc_simple_card snd_soc_simple_card_utils v4l2_vp9 v4l2_h264 rockchip_saradc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rtc_rk808 videobuf2_v4l2 industrialio_triggered_buffer rockchip_thermal dwmac_rk stmmac_platform stmmac videodev kfifo_buf display_connector videobuf2_common pcs_xpcs mc rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi drm_display_helper panfrost drm_shmem_helper gpu_sched ip_tables x_tables ipv6 > > CPU: 3 PID: 176 Comm: v4l_id Not tainted 6.3.0-rc7-next-20230420 #13481 > > Hardware name: Hardkernel ODROID-M1 (DT) > > pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > pc : hantro_try_fmt+0xa0/0x278 [hantro_vpu] > > lr : hantro_try_fmt+0x94/0x278 [hantro_vpu] > > ... > > Call trace: > > hantro_try_fmt+0xa0/0x278 [hantro_vpu] > > hantro_set_fmt_out+0x3c/0x298 [hantro_vpu] > > hantro_reset_raw_fmt+0x98/0x128 [hantro_vpu] > > hantro_set_fmt_cap+0x240/0x254 [hantro_vpu] > > hantro_reset_encoded_fmt+0x94/0xcc [hantro_vpu] > > hantro_reset_fmts+0x18/0x38 [hantro_vpu] > > hantro_open+0xd4/0x20c [hantro_vpu] > > v4l2_open+0x80/0x120 [videodev] > > chrdev_open+0xc0/0x22c > > do_dentry_open+0x13c/0x48c > > vfs_open+0x2c/0x38 > > path_openat+0x550/0x934 > > do_filp_open+0x80/0x12c > > do_sys_openat2+0xb4/0x168 > > __arm64_sys_openat+0x64/0xac > > invoke_syscall+0x48/0x114 > > el0_svc_common+0x100/0x120 > > do_el0_svc+0x3c/0xa8 > > el0_svc+0x40/0xa8 > > el0t_64_sync_handler+0xb8/0xbc > > el0t_64_sync+0x190/0x194 > > Code: 97fc8a7f f940aa80 52864a61 72a686c1 (b9400800) > > ---[ end trace 0000000000000000 ]--- > > > > Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions") This patch partially reverts the previous commit. I wonder whether the reason for resetting the context format only if the targeted queue is not busy still stands. > > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Tested-by: Michael Tretter <m.tretter@pengutronix.de> > > --- > > Diederick, Marek, Michael, > I have tested this patch on my boards and I see no regressions on > decoder part and no more crash when probing the encoder. > Could you test it on your side to confirm it is ok ? > > Thorsten, I try/test regzbot commands, please tell me if it is correct. > > #regzbot ^introduced db6f68b51e5c > #regzbot title media: verisilicon: null pointer dereference in try_fmt > #regzbot ignore-activity > > > > drivers/media/platform/verisilicon/hantro_v4l2.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c > > index 835518534e3b..61cfaaf4e927 100644 > > --- a/drivers/media/platform/verisilicon/hantro_v4l2.c > > +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c > > @@ -397,10 +397,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth) > > if (!raw_vpu_fmt) > > return -EINVAL; > > - if (ctx->is_encoder) > > + if (ctx->is_encoder) { > > encoded_fmt = &ctx->dst_fmt; > > - else > > + ctx->vpu_src_fmt = raw_vpu_fmt; > > + } else { > > encoded_fmt = &ctx->src_fmt; > > + } > > hantro_reset_fmt(&raw_fmt, raw_vpu_fmt); > > raw_fmt.width = encoded_fmt->width; >
Hi guys, After reviewing the format logic (hantro_reset_encoded_fmt and hantro_reset_raw_fmt). It seems to me trying to support Decoders, Encoders and so many different SoC Variants, is getting increasingly fragile. This driver is becoming a big fat monolith. Regressions like this will be increasingly frequent. The only codec that supports encoding right now is JPEG, so I think it's a good idea to remove it for good, and split it to its own driver. Anyone volunteering? :-) Thanks, Ezequiel On Tue, May 23, 2023 at 2:06 PM Michael Tretter <m.tretter@pengutronix.de> wrote: > > On Tue, 23 May 2023 18:36:09 +0200, Benjamin Gaignard wrote: > > > > Le 23/05/2023 à 18:25, Benjamin Gaignard a écrit : > > > This fixes the following issue observed on Odroid-M1 board: > > > > > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 > > > Mem abort info: > > > ... > > > Modules linked in: crct10dif_ce hantro_vpu snd_soc_simple_card snd_soc_simple_card_utils v4l2_vp9 v4l2_h264 rockchip_saradc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rtc_rk808 videobuf2_v4l2 industrialio_triggered_buffer rockchip_thermal dwmac_rk stmmac_platform stmmac videodev kfifo_buf display_connector videobuf2_common pcs_xpcs mc rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi drm_display_helper panfrost drm_shmem_helper gpu_sched ip_tables x_tables ipv6 > > > CPU: 3 PID: 176 Comm: v4l_id Not tainted 6.3.0-rc7-next-20230420 #13481 > > > Hardware name: Hardkernel ODROID-M1 (DT) > > > pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > pc : hantro_try_fmt+0xa0/0x278 [hantro_vpu] > > > lr : hantro_try_fmt+0x94/0x278 [hantro_vpu] > > > ... > > > Call trace: > > > hantro_try_fmt+0xa0/0x278 [hantro_vpu] > > > hantro_set_fmt_out+0x3c/0x298 [hantro_vpu] > > > hantro_reset_raw_fmt+0x98/0x128 [hantro_vpu] > > > hantro_set_fmt_cap+0x240/0x254 [hantro_vpu] > > > hantro_reset_encoded_fmt+0x94/0xcc [hantro_vpu] > > > hantro_reset_fmts+0x18/0x38 [hantro_vpu] > > > hantro_open+0xd4/0x20c [hantro_vpu] > > > v4l2_open+0x80/0x120 [videodev] > > > chrdev_open+0xc0/0x22c > > > do_dentry_open+0x13c/0x48c > > > vfs_open+0x2c/0x38 > > > path_openat+0x550/0x934 > > > do_filp_open+0x80/0x12c > > > do_sys_openat2+0xb4/0x168 > > > __arm64_sys_openat+0x64/0xac > > > invoke_syscall+0x48/0x114 > > > el0_svc_common+0x100/0x120 > > > do_el0_svc+0x3c/0xa8 > > > el0_svc+0x40/0xa8 > > > el0t_64_sync_handler+0xb8/0xbc > > > el0t_64_sync+0x190/0x194 > > > Code: 97fc8a7f f940aa80 52864a61 72a686c1 (b9400800) > > > ---[ end trace 0000000000000000 ]--- > > > > > > Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions") > > This patch partially reverts the previous commit. I wonder whether the reason > for resetting the context format only if the targeted queue is not busy still > stands. > > > > > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> > > Tested-by: Michael Tretter <m.tretter@pengutronix.de> > > > > --- > > > > Diederick, Marek, Michael, > > I have tested this patch on my boards and I see no regressions on > > decoder part and no more crash when probing the encoder. > > Could you test it on your side to confirm it is ok ? > > > > Thorsten, I try/test regzbot commands, please tell me if it is correct. > > > > #regzbot ^introduced db6f68b51e5c > > #regzbot title media: verisilicon: null pointer dereference in try_fmt > > #regzbot ignore-activity > > > > > > > drivers/media/platform/verisilicon/hantro_v4l2.c | 6 ++++-- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c > > > index 835518534e3b..61cfaaf4e927 100644 > > > --- a/drivers/media/platform/verisilicon/hantro_v4l2.c > > > +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c > > > @@ -397,10 +397,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth) > > > if (!raw_vpu_fmt) > > > return -EINVAL; > > > - if (ctx->is_encoder) > > > + if (ctx->is_encoder) { > > > encoded_fmt = &ctx->dst_fmt; > > > - else > > > + ctx->vpu_src_fmt = raw_vpu_fmt; > > > + } else { > > > encoded_fmt = &ctx->src_fmt; > > > + } > > > hantro_reset_fmt(&raw_fmt, raw_vpu_fmt); > > > raw_fmt.width = encoded_fmt->width; > >
On Tuesday, 23 May 2023 18:36:09 CEST Benjamin Gaignard wrote: > Diederik, Marek, Michael, > I have tested this patch on my boards and I see no regressions on > decoder part and no more crash when probing the encoder. > Could you test it on your side to confirm it is ok ? With this patch I'm (also) not seeing the crash Tested-by: Diederik de Haas <didi.debian@cknow.org>
Le mardi 23 mai 2023 à 14:36 -0300, Ezequiel Garcia a écrit : > Hi guys, > > After reviewing the format logic (hantro_reset_encoded_fmt and > hantro_reset_raw_fmt). > It seems to me trying to support Decoders, Encoders and so many > different SoC Variants, is getting increasingly fragile. > This driver is becoming a big fat monolith. Regressions like this will > be increasingly frequent. > > The only codec that supports encoding right now is JPEG, so I think > it's a good idea to remove it for good, > and split it to its own driver. > > Anyone volunteering? :-) We won't have that luxury with VP8 and H.264, as the decoder and encoder shares the same cache memory. They must be time sliced. Note that this driver is only missing VP8/H.264 encoding before it becomes maintenance only (there won't be any interesting feature left, so I would not start on big refactoring, as this may cause more trouble then good. Anything newer like VC8000 or VC9000 should be a new driver, and with encoder/decoder split. regards, Nicolas p.s. this is my personal opinion, in general, we should improve the helpers if there is too much boilerplate, rather then creating monolithic drivers, and on that, I believe I agree, but the H1/G1 combo have hardware dependencies which has been solve that way, and changing that now is a big amount of work for a relative quite driver. Feel free to split G2 away from that driver, that would make sense, its not sharing anything. > > Thanks, > Ezequiel > > On Tue, May 23, 2023 at 2:06 PM Michael Tretter > <m.tretter@pengutronix.de> wrote: > > > > On Tue, 23 May 2023 18:36:09 +0200, Benjamin Gaignard wrote: > > > > > > Le 23/05/2023 à 18:25, Benjamin Gaignard a écrit : > > > > This fixes the following issue observed on Odroid-M1 board: > > > > > > > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 > > > > Mem abort info: > > > > ... > > > > Modules linked in: crct10dif_ce hantro_vpu snd_soc_simple_card snd_soc_simple_card_utils v4l2_vp9 v4l2_h264 rockchip_saradc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rtc_rk808 videobuf2_v4l2 industrialio_triggered_buffer rockchip_thermal dwmac_rk stmmac_platform stmmac videodev kfifo_buf display_connector videobuf2_common pcs_xpcs mc rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi drm_display_helper panfrost drm_shmem_helper gpu_sched ip_tables x_tables ipv6 > > > > CPU: 3 PID: 176 Comm: v4l_id Not tainted 6.3.0-rc7-next-20230420 #13481 > > > > Hardware name: Hardkernel ODROID-M1 (DT) > > > > pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > > > pc : hantro_try_fmt+0xa0/0x278 [hantro_vpu] > > > > lr : hantro_try_fmt+0x94/0x278 [hantro_vpu] > > > > ... > > > > Call trace: > > > > hantro_try_fmt+0xa0/0x278 [hantro_vpu] > > > > hantro_set_fmt_out+0x3c/0x298 [hantro_vpu] > > > > hantro_reset_raw_fmt+0x98/0x128 [hantro_vpu] > > > > hantro_set_fmt_cap+0x240/0x254 [hantro_vpu] > > > > hantro_reset_encoded_fmt+0x94/0xcc [hantro_vpu] > > > > hantro_reset_fmts+0x18/0x38 [hantro_vpu] > > > > hantro_open+0xd4/0x20c [hantro_vpu] > > > > v4l2_open+0x80/0x120 [videodev] > > > > chrdev_open+0xc0/0x22c > > > > do_dentry_open+0x13c/0x48c > > > > vfs_open+0x2c/0x38 > > > > path_openat+0x550/0x934 > > > > do_filp_open+0x80/0x12c > > > > do_sys_openat2+0xb4/0x168 > > > > __arm64_sys_openat+0x64/0xac > > > > invoke_syscall+0x48/0x114 > > > > el0_svc_common+0x100/0x120 > > > > do_el0_svc+0x3c/0xa8 > > > > el0_svc+0x40/0xa8 > > > > el0t_64_sync_handler+0xb8/0xbc > > > > el0t_64_sync+0x190/0x194 > > > > Code: 97fc8a7f f940aa80 52864a61 72a686c1 (b9400800) > > > > ---[ end trace 0000000000000000 ]--- > > > > > > > > Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions") > > > > This patch partially reverts the previous commit. I wonder whether the reason > > for resetting the context format only if the targeted queue is not busy still > > stands. > > > > > > > > > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> > > > > Tested-by: Michael Tretter <m.tretter@pengutronix.de> > > > > > > --- > > > > > > Diederick, Marek, Michael, > > > I have tested this patch on my boards and I see no regressions on > > > decoder part and no more crash when probing the encoder. > > > Could you test it on your side to confirm it is ok ? > > > > > > Thorsten, I try/test regzbot commands, please tell me if it is correct. > > > > > > #regzbot ^introduced db6f68b51e5c > > > #regzbot title media: verisilicon: null pointer dereference in try_fmt > > > #regzbot ignore-activity > > > > > > > > > > drivers/media/platform/verisilicon/hantro_v4l2.c | 6 ++++-- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c > > > > index 835518534e3b..61cfaaf4e927 100644 > > > > --- a/drivers/media/platform/verisilicon/hantro_v4l2.c > > > > +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c > > > > @@ -397,10 +397,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth) > > > > if (!raw_vpu_fmt) > > > > return -EINVAL; > > > > - if (ctx->is_encoder) > > > > + if (ctx->is_encoder) { > > > > encoded_fmt = &ctx->dst_fmt; > > > > - else > > > > + ctx->vpu_src_fmt = raw_vpu_fmt; > > > > + } else { > > > > encoded_fmt = &ctx->src_fmt; > > > > + } > > > > hantro_reset_fmt(&raw_fmt, raw_vpu_fmt); > > > > raw_fmt.width = encoded_fmt->width; > > >
On 23.05.2023 18:25, Benjamin Gaignard wrote: > This fixes the following issue observed on Odroid-M1 board: > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 > Mem abort info: > ... > Modules linked in: crct10dif_ce hantro_vpu snd_soc_simple_card snd_soc_simple_card_utils v4l2_vp9 v4l2_h264 rockchip_saradc v4l2_mem2mem videobuf2_dma_contig videobuf2_memops rtc_rk808 videobuf2_v4l2 industrialio_triggered_buffer rockchip_thermal dwmac_rk stmmac_platform stmmac videodev kfifo_buf display_connector videobuf2_common pcs_xpcs mc rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi drm_display_helper panfrost drm_shmem_helper gpu_sched ip_tables x_tables ipv6 > CPU: 3 PID: 176 Comm: v4l_id Not tainted 6.3.0-rc7-next-20230420 #13481 > Hardware name: Hardkernel ODROID-M1 (DT) > pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : hantro_try_fmt+0xa0/0x278 [hantro_vpu] > lr : hantro_try_fmt+0x94/0x278 [hantro_vpu] > ... > Call trace: > hantro_try_fmt+0xa0/0x278 [hantro_vpu] > hantro_set_fmt_out+0x3c/0x298 [hantro_vpu] > hantro_reset_raw_fmt+0x98/0x128 [hantro_vpu] > hantro_set_fmt_cap+0x240/0x254 [hantro_vpu] > hantro_reset_encoded_fmt+0x94/0xcc [hantro_vpu] > hantro_reset_fmts+0x18/0x38 [hantro_vpu] > hantro_open+0xd4/0x20c [hantro_vpu] > v4l2_open+0x80/0x120 [videodev] > chrdev_open+0xc0/0x22c > do_dentry_open+0x13c/0x48c > vfs_open+0x2c/0x38 > path_openat+0x550/0x934 > do_filp_open+0x80/0x12c > do_sys_openat2+0xb4/0x168 > __arm64_sys_openat+0x64/0xac > invoke_syscall+0x48/0x114 > el0_svc_common+0x100/0x120 > do_el0_svc+0x3c/0xa8 > el0_svc+0x40/0xa8 > el0t_64_sync_handler+0xb8/0xbc > el0t_64_sync+0x190/0x194 > Code: 97fc8a7f f940aa80 52864a61 72a686c1 (b9400800) > ---[ end trace 0000000000000000 ]--- > > Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions") > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > --- > drivers/media/platform/verisilicon/hantro_v4l2.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c > index 835518534e3b..61cfaaf4e927 100644 > --- a/drivers/media/platform/verisilicon/hantro_v4l2.c > +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c > @@ -397,10 +397,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth) > if (!raw_vpu_fmt) > return -EINVAL; > > - if (ctx->is_encoder) > + if (ctx->is_encoder) { > encoded_fmt = &ctx->dst_fmt; > - else > + ctx->vpu_src_fmt = raw_vpu_fmt; > + } else { > encoded_fmt = &ctx->src_fmt; > + } > > hantro_reset_fmt(&raw_fmt, raw_vpu_fmt); > raw_fmt.width = encoded_fmt->width; Best regards
Linux regression tracking (Thorsten Leemhuis)
May 24, 2023, 9:06 a.m. UTC |
#7
Addressed
Unaddressed
On 23.05.23 18:36, Benjamin Gaignard wrote: > > Le 23/05/2023 à 18:25, Benjamin Gaignard a écrit : >> This fixes the following issue observed on Odroid-M1 board: > [...] > Diederick, Marek, Michael, > I have tested this patch on my boards and I see no regressions on > decoder part and no more crash when probing the encoder. > Could you test it on your side to confirm it is ok ? They all did, so that is done. Thx for your help, everybody! /me now hopes this patch will be quickly reviewed, accepted and sent to Linus to prevent even more people running into this... > Thorsten, I try/test regzbot commands, please tell me if it is correct. > > #regzbot ^introduced db6f68b51e5c > #regzbot title media: verisilicon: null pointer dereference in try_fmt > #regzbot ignore-activity Thx for this, we just now track this regression two times. No worries, let me fix this and also tell regzbot about the fix: #regzbot dup-of: https://lore.kernel.org/lkml/4995215.LvFx2qVVIh@bagend/ #regzbot fix: media: verisilicon: Additional fix for the crash when opening the driver Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
On 24/05/2023 11:06, Thorsten Leemhuis wrote: > On 23.05.23 18:36, Benjamin Gaignard wrote: >> >> Le 23/05/2023 à 18:25, Benjamin Gaignard a écrit : >>> This fixes the following issue observed on Odroid-M1 board: >> [...] >> Diederick, Marek, Michael, >> I have tested this patch on my boards and I see no regressions on >> decoder part and no more crash when probing the encoder. >> Could you test it on your side to confirm it is ok ? > > They all did, so that is done. Thx for your help, everybody! > > /me now hopes this patch will be quickly reviewed, accepted and sent to > Linus to prevent even more people running into this... I plan to make a PR with 6.4 fixes today or tomorrow. Regards, Hans > >> Thorsten, I try/test regzbot commands, please tell me if it is correct. >> >> #regzbot ^introduced db6f68b51e5c >> #regzbot title media: verisilicon: null pointer dereference in try_fmt >> #regzbot ignore-activity > > Thx for this, we just now track this regression two times. No worries, > let me fix this and also tell regzbot about the fix: > > #regzbot dup-of: https://lore.kernel.org/lkml/4995215.LvFx2qVVIh@bagend/ > #regzbot fix: media: verisilicon: Additional fix for the crash when > opening the driver > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > If I did something stupid, please tell me, as explained on that page.
Linux regression tracking (Thorsten Leemhuis)
May 24, 2023, 9:22 a.m. UTC |
#9
Addressed
Unaddressed
On 24.05.23 11:15, Hans Verkuil wrote: > On 24/05/2023 11:06, Thorsten Leemhuis wrote: >> On 23.05.23 18:36, Benjamin Gaignard wrote: >>> >>> Le 23/05/2023 à 18:25, Benjamin Gaignard a écrit : >>>> This fixes the following issue observed on Odroid-M1 board: >>> [...] >>> Diederick, Marek, Michael, >>> I have tested this patch on my boards and I see no regressions on >>> decoder part and no more crash when probing the encoder. >>> Could you test it on your side to confirm it is ok ? >> >> They all did, so that is done. Thx for your help, everybody! >> >> /me now hopes this patch will be quickly reviewed, accepted and sent to >> Linus to prevent even more people running into this... > > I plan to make a PR with 6.4 fixes today or tomorrow. Ahh, fabulous, many thx! Ciao, Thorsten
diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c index 835518534e3b..61cfaaf4e927 100644 --- a/drivers/media/platform/verisilicon/hantro_v4l2.c +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c @@ -397,10 +397,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth) if (!raw_vpu_fmt) return -EINVAL; - if (ctx->is_encoder) + if (ctx->is_encoder) { encoded_fmt = &ctx->dst_fmt; - else + ctx->vpu_src_fmt = raw_vpu_fmt; + } else { encoded_fmt = &ctx->src_fmt; + } hantro_reset_fmt(&raw_fmt, raw_vpu_fmt); raw_fmt.width = encoded_fmt->width;