linux-kernel - Re: [PATCH v3] media: venus: amend buffer size for bitstream plane

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAFQd5DJn-_y5dHySAB6_ed-syBOr3Ybo7KfsPLNd+0Z7X0N7g@mail.gmail.com>
Date:   Tue, 27 Nov 2018 00:44:23 +0900
From:   Tomasz Figa <tfiga@...omium.org>
To:     Hans Verkuil <hverkuil@...all.nl>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        mgottam@...eaurora.org, Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Alexandre Courbot <acourbot@...omium.org>,
        vgarodia@...eaurora.org
Subject: Re: [PATCH v3] media: venus: amend buffer size for bitstream plane

Hi Hans,

On Tue, Nov 27, 2018 at 12:24 AM Hans Verkuil <hverkuil@...all.nl> wrote:
>
> On 11/26/2018 03:57 PM, Stanimir Varbanov wrote:
> > Hi Hans,
> >
> > On 11/26/18 3:37 PM, Hans Verkuil wrote:
> >> On 11/26/2018 11:12 AM, Malathi Gottam wrote:
> >>> Accept the buffer size requested by client and compare it
> >>> against driver calculated size and set the maximum to
> >>> bitstream plane.
> >>>
> >>> Signed-off-by: Malathi Gottam <mgottam@...eaurora.org>
> >>
> >> Sorry, this isn't allowed. It is the driver that sets the sizeimage value,
> >> never the other way around.
> >
> > I think for decoders (OUTPUT queue) and encoders (CAPTURE queue) we
> > allowed userspace to set sizeimage for buffers. See [1] Initialization
> > paragraph point 2:
> >
> >     ``sizeimage``
> >        desired size of ``CAPTURE`` buffers; the encoder may adjust it to
> >        match hardware requirements
> >
> > Similar patch we be needed for decoder as well.
>
> I may have missed that change since it wasn't present in v1 of the stateful
> encoder spec.

It's been there from the very beginning, even before I started working
on it. Actually, even the early slides from Kamil mention the
application setting the buffer size for compressed streams:
https://events.static.linuxfound.org/images/stories/pdf/lceu2012_debski.pdf

>
> Tomasz, what was the reason for this change? I vaguely remember some thread
> about this, but I forgot the details. Since this would be a departure of
> the current API this should be explained in more detail.

The kernel is not the place to encode assumptions about optimal
bitstream chunk sizes. It depends on the use case and the application
should be able decide. It may for example want to use smaller buffers,
optimizing for the well compressible video streams and just reallocate
if bigger chunks are needed.

>
> I don't really see the point of requiring userspace to fill this in. For
> stateful codecs it can just return some reasonable size. Possibly calculated
> using the provided width/height values or (if those are 0) some default value.

How do we decide what's "reasonable"? Would it be reasonable for all
applications?

>
> Ditto for decoders.
>
> Stanimir, I certainly cannot merge this until this has been fully nailed down
> as it would be a departure from the current API.

It would not be a departure, because I can see existing stateful
drivers behaving like that:
https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L1444
https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c#L469

Also, Chromium has been setting the size on its own for long time
using its own heuristics.

>
> And looking at the venus patch I do not see how it helps userspace.
>
> Regards,
>
>         Hans
>
> >
> >>
> >> If you need to allocate larger buffers, then use VIDIOC_CREATE_BUFS instead
> >> of VIDIOC_REQBUFS.

CREATE_BUFS wouldn't work, because one needs to use TRY_FMT to obtain
a format for it and the format returned by it would have the sizeimage
as hardcoded in the driver...

Best regards,
Tomasz