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: <b7122cb49cfa0bcfa433c154f6cb64ee0dba55da.camel@ndufresne.ca>
Date:   Wed, 13 May 2020 19:38:32 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Ezequiel Garcia <ezequiel@...labora.com>,
        Tomasz Figa <tfiga@...omium.org>
Cc:     Linux Media Mailing List <linux-media@...r.kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel@...labora.com, Jonas Karlman <jonas@...boo.se>,
        Heiko Stuebner <heiko@...ech.de>,
        Hans Verkuil <hverkuil@...all.nl>,
        Alexandre Courbot <acourbot@...omium.org>,
        Jeffrey Kardatzke <jkardatzke@...omium.org>,
        Gustavo Padovan <gustavo.padovan@...labora.com>
Subject: Re: [PATCH v3 1/3] media: rkvdec: Fix .buf_prepare

Le mardi 05 mai 2020 à 11:27 -0300, Ezequiel Garcia a écrit :
> On Tue, 2020-05-05 at 16:05 +0200, Tomasz Figa wrote:
> > On Tue, May 5, 2020 at 3:59 PM Ezequiel Garcia <ezequiel@...labora.com> wrote:
> > > On Tue, 2020-05-05 at 15:56 +0200, Tomasz Figa wrote:
> > > > Hi Ezequiel,
> > > > 
> > > > On Tue, May 5, 2020 at 3:41 PM Ezequiel Garcia <ezequiel@...labora.com> wrote:
> > > > > The driver should only set the payload on .buf_prepare
> > > > > if the buffer is CAPTURE type, or if an OUTPUT buffer
> > > > > has a zeroed payload.
> > > > 
> > > > Thanks for the patch. Just one question below.
> > > > 
> > > > Where does the requirement to set OUTPUT buffer bytesused to sizeimage
> > > > if the original bytesused is 0 come from?
> > > > 
> > > 
> > > If I'm reading english correctly, it's here:
> > > 
> > > https://www.kernel.org/doc/html/latest/media/uapi/v4l/buffer.html
> > > 
> > > """
> > > The number of bytes occupied by the data in the buffer. It depends on the negotiated data format and may change with each buffer for compressed
> > > variable size data like JPEG images. Drivers must set this field when type refers to a capture stream, applications when it refers to an output
> > > stream. If the application sets this to 0 for an output stream, then bytesused will be set to the size of the buffer (see the length field of this
> > > struct) by the driver. For multiplanar formats this field is ignored and the planes pointer is used instead.
> > > """
> > 
> > Okay, thanks. I wonder if this shouldn't be handled by the core,
> > though. Especially given that the document refers to the length field
> > specifically and not the sizeimage set in the format.
> > 
> 
> Yes, either core or helper, this definitely calls for a generic solution.

For the context, this is for backward compatibility. I'm not certain it
make sense for new driver interface like RKVDEC. Specially that if the
user did pass an empty buffer by accident, this will push garbage into
the driver. That being said, it seems to match the spec.

> 
> Ezequiel
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ