linux-kernel - Re: [PATCH v1 5/5] media: rkvdec: Improve error handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220610191413.xgwfw5n6snje3khj@basti-XPS-13-9310>
Date:   Fri, 10 Jun 2022 21:14:13 +0200
From:   Sebastian Fricke <sebastian.fricke@...labora.com>
To:     Nicolas Dufresne <nicolas.dufresne@...labora.com>
Cc:     linux-media@...r.kernel.org,
        Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        kernel@...labora.com, linux-rockchip@...ts.infradead.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 5/5] media: rkvdec: Improve error handling

Hey Nicolas,

Tested with: python3 fluster.py run -d GStreamer-H.264-V4L2SL-Gst1.0 -ts JVT-AVC_
V1 -so /tmp/h264_test.csv -f csv -j1

Ran 129/135 tests successfully               in 82.280 secs

On 10.06.2022 08:52, Nicolas Dufresne wrote:
>There is two way decode errors can occur. In one case, the ready

s/There is two way decode/There are two ways decoding/


>status is not set and nothing have been written into the destination,

s/nothing have been/nothing has been/

>while in the other case, the buffer is written but may contain a
>certain amount of errors. In order to differentiate these, we set
>the payload for the first case to 0.
>
>Signed-off-by: Nicolas Dufresne <nicolas.dufresne@...labora.com>
Tested-by: Sebastian Fricke <sebastian.fricke@...labora.com>

>---
> drivers/staging/media/rkvdec/rkvdec.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c
>index 7e76f8b72885..27f1f7276dd2 100644
>--- a/drivers/staging/media/rkvdec/rkvdec.c
>+++ b/drivers/staging/media/rkvdec/rkvdec.c
>@@ -954,14 +954,32 @@ static irqreturn_t rkvdec_irq_handler(int irq, void *priv)
> 	enum vb2_buffer_state state;
> 	u32 status;
>
>+	ctx = v4l2_m2m_get_curr_priv(rkvdec->m2m_dev);
> 	status = readl(rkvdec->regs + RKVDEC_REG_INTERRUPT);
>-	state = (status & RKVDEC_RDY_STA) ?
>-		VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
>+
>+	if (!(status & RKVDEC_RDY_STA)) {
>+		struct vb2_v4l2_buffer *dst_buf = NULL;
>+
>+		if (status & RKVDEC_TIMEOUT_STA)
>+			pr_debug("Decoder stopped due to internal timeout.");
>+		else
>+			pr_debug("Decoder stopped due to internal error.");

(Just personal preference.. I would prefer "due to an internal" over
"due to internal")

>+
>+		/*
>+		 * When this happens, the buffer is left unmodified. As it
>+		 * contains no meaningful data we mark is a empty.

s/is a empty/it as empty/

The rest looks nice. Thanks.

Greetings,
Sebastian

>+		 */
>+		dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
>+		vb2_set_plane_payload(&dst_buf->vb2_buf, 0, 0);
>+		state = VB2_BUF_STATE_ERROR;
>+	} else {
>+		state = VB2_BUF_STATE_DONE;
>+	}
>
> 	writel(0, rkvdec->regs + RKVDEC_REG_INTERRUPT);
>-	ctx = v4l2_m2m_get_curr_priv(rkvdec->m2m_dev);
>
>-	if (ctx->coded_fmt_desc->ops->check_error_info)
>+	if (ctx->coded_fmt_desc->ops->check_error_info &&
>+	    state == VB2_BUF_STATE_DONE)
> 		state = ctx->coded_fmt_desc->ops->check_error_info(ctx);
>
> 	if (cancel_delayed_work(&rkvdec->watchdog_work))
>-- 
>2.36.1
>