| Message ID | 20220620175517.648767-6-jernej.skrabec@gmail.com |
|---|---|
| State | Accepted |
| Commit | 0ede8c820ae0bdf7036127934521c6ea8376fc5f |
| Headers | show |
| Series | media: cedrus: h265: Implement tiles support | expand |
On Mon, Jun 20, 2022 at 07:55:15PM +0200, Jernej Skrabec wrote: > Now that we have infrastructure for reporting errors, let's add two > checks, which will make sure slice can be actually decoded. > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> > --- > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > index cfde4ccf6011..99020b9f9ff8 100644 > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c Now that you've allowed setup to fail, I would suggest to have some documentation/comments on struct cedrus_dec_ops, to set the expectation/rules for each ops, including the call paths for each operation, which of them are allowed to sleep, etc. > @@ -435,9 +435,17 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, struct cedrus_run *run) > * instead of start of slice data. Padding is 8 bits at most (one bit set to 1 and > * at most seven bits set to 0), so we have to inspect only one byte before slice data. > */ > + > + if (slice_params->data_byte_offset == 0) > + return -EOPNOTSUPP; > + AFAICS, cedrus_h265_setup is called from .device_run. We've been discussing control validation before, and I think the ideal place to do that is v4l2_ctrl_ops.s_ctrl, if that's at all possible. Driver's mem2mem device_run are executed in the context of a work_struct and the failure won't really get reported up the stack. > padding = (u8 *)vb2_plane_vaddr(&run->src->vb2_buf, 0) + > slice_params->data_byte_offset - 1; > > + /* at least one bit must be set in that byte */ > + if (*padding == 0) > + return -EINVAL; > + Maybe this is something to check at cedrus_buf_prepare(), when the buffer is queued? Thanks, Ezequiel > for (count = 0; count < 8; count++) > if (*padding & (1 << count)) > break; > -- > 2.36.1 >
Hi Ezequiel. Dne ponedeljek, 11. julij 2022 ob 23:31:11 CEST je Ezequiel Garcia napisal(a): > On Mon, Jun 20, 2022 at 07:55:15PM +0200, Jernej Skrabec wrote: > > Now that we have infrastructure for reporting errors, let's add two > > checks, which will make sure slice can be actually decoded. > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> > > --- > > > > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index > > cfde4ccf6011..99020b9f9ff8 100644 > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > Now that you've allowed setup to fail, I would suggest > to have some documentation/comments on struct cedrus_dec_ops, > to set the expectation/rules for each ops, including the > call paths for each operation, which of them are allowed to sleep, > etc. Documentation can be always added, but it should be separate patch. > > > @@ -435,9 +435,17 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, > > struct cedrus_run *run)> > > * instead of start of slice data. Padding is 8 bits at most (one bit > > set to 1 and * at most seven bits set to 0), so we have to inspect > > only one byte before slice data. */ > > > > + > > + if (slice_params->data_byte_offset == 0) > > + return -EOPNOTSUPP; > > + > > AFAICS, cedrus_h265_setup is called from .device_run. > We've been discussing control validation before, and I think the > ideal place to do that is v4l2_ctrl_ops.s_ctrl, if that's > at all possible. Yeah, this particular check can be moved to s_ctrl handler. > > Driver's mem2mem device_run are executed in the context > of a work_struct and the failure won't really get reported > up the stack. Well, at least there will be a notice in dmesg. Not ideal, I know. > > > padding = (u8 *)vb2_plane_vaddr(&run->src->vb2_buf, 0) + > > > > slice_params->data_byte_offset - 1; > > > > + /* at least one bit must be set in that byte */ > > + if (*padding == 0) > > + return -EINVAL; > > + > > Maybe this is something to check at cedrus_buf_prepare(), > when the buffer is queued? I don't think so. This check is HEVC specific, but cedrus_buf_prepare() is not and we need to have slice control ready, which I'm not sure is the case for cedrus_buf_prepare(). Best regards, Jernej > > Thanks, > Ezequiel > > > for (count = 0; count < 8; count++) > > > > if (*padding & (1 << count)) > > > > break; > > > > -- > > 2.36.1
Hi Jernej, On Tue, Jul 12, 2022 at 11:25:00PM +0200, Jernej Škrabec wrote: > Hi Ezequiel. > > Dne ponedeljek, 11. julij 2022 ob 23:31:11 CEST je Ezequiel Garcia napisal(a): > > On Mon, Jun 20, 2022 at 07:55:15PM +0200, Jernej Skrabec wrote: > > > Now that we have infrastructure for reporting errors, let's add two > > > checks, which will make sure slice can be actually decoded. > > > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> > > > --- > > > > > > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > > b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index > > > cfde4ccf6011..99020b9f9ff8 100644 > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > > > Now that you've allowed setup to fail, I would suggest > > to have some documentation/comments on struct cedrus_dec_ops, > > to set the expectation/rules for each ops, including the > > call paths for each operation, which of them are allowed to sleep, > > etc. > > Documentation can be always added, but it should be separate patch. > Of course, this wasn't a comment meant to block the patch in any way. > > > > > @@ -435,9 +435,17 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, > > > struct cedrus_run *run)> > > > * instead of start of slice data. Padding is 8 bits at most (one > bit > > > set to 1 and * at most seven bits set to 0), so we have to > inspect > > > only one byte before slice data. */ > > > > > > + > > > + if (slice_params->data_byte_offset == 0) > > > + return -EOPNOTSUPP; > > > + > > > > AFAICS, cedrus_h265_setup is called from .device_run. > > We've been discussing control validation before, and I think the > > ideal place to do that is v4l2_ctrl_ops.s_ctrl, if that's > > at all possible. > > Yeah, this particular check can be moved to s_ctrl handler. > > > > > Driver's mem2mem device_run are executed in the context > > of a work_struct and the failure won't really get reported > > up the stack. > > Well, at least there will be a notice in dmesg. Not ideal, I know. > > > > > > padding = (u8 *)vb2_plane_vaddr(&run->src->vb2_buf, 0) + > > > > > > slice_params->data_byte_offset - 1; > > > > > > + /* at least one bit must be set in that byte */ > > > + if (*padding == 0) > > > + return -EINVAL; > > > + > > > > Maybe this is something to check at cedrus_buf_prepare(), > > when the buffer is queued? > > I don't think so. This check is HEVC specific, but cedrus_buf_prepare() is not > and we need to have slice control ready, which I'm not sure is the case for > cedrus_buf_prepare(). > Hm... this is indeed a special case. The buffer contents depend on a control, and both buffer and control are part of the same request. At least the decoding job would fail, and would get signaled by the dequeued CAPTURE buffers and the V4L2_BUF_FLAG_ERROR flag, which makes perfect sense. In general vb2_ops.buf_prepare() is called for each buffer (either through VIDIOC_QBUF or through MEDIA_REQUEST_IOC_QUEUE), so for some buffer validations .buf_prepare() _might_ work better than .device_run for validation. In any case, the patch looks good, I don't think these comments should block the patch: Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Thanks, Ezequiel > Best regards, > Jernej > > > > > Thanks, > > Ezequiel > > > > > for (count = 0; count < 8; count++) > > > > > > if (*padding & (1 << count)) > > > > > > break; > > > > > > -- > > > 2.36.1 > >
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index cfde4ccf6011..99020b9f9ff8 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c @@ -435,9 +435,17 @@ static int cedrus_h265_setup(struct cedrus_ctx *ctx, struct cedrus_run *run) * instead of start of slice data. Padding is 8 bits at most (one bit set to 1 and * at most seven bits set to 0), so we have to inspect only one byte before slice data. */ + + if (slice_params->data_byte_offset == 0) + return -EOPNOTSUPP; + padding = (u8 *)vb2_plane_vaddr(&run->src->vb2_buf, 0) + slice_params->data_byte_offset - 1; + /* at least one bit must be set in that byte */ + if (*padding == 0) + return -EINVAL; + for (count = 0; count < 8; count++) if (*padding & (1 << count)) break;
Now that we have infrastructure for reporting errors, let's add two checks, which will make sure slice can be actually decoded. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> --- drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 8 ++++++++ 1 file changed, 8 insertions(+)