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]
Date:   Wed, 04 Oct 2017 17:18:04 -0300
From:   Gustavo Padovan <gustavo.padovan@...labora.com>
To:     Brian Starkey <brian.starkey@....com>,
        Gustavo Padovan <gustavo@...ovan.org>
Cc:     linux-media@...r.kernel.org, Hans Verkuil <hverkuil@...all.nl>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        Shuah Khan <shuahkh@....samsung.com>,
        linux-kernel@...r.kernel.org, Jonathan.Chai@....com
Subject: Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues

On Mon, 2017-10-02 at 14:43 +0100, Brian Starkey wrote:
> Hi,
> 
> On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@...labora.com>
> > 
> > For explicit synchronization (and soon for HAL3/Request API) we
> > need
> > the v4l2-driver to guarantee the ordering in which the buffers were
> > queued
> > by userspace. This is already true for many drivers, but we never
> > needed
> > to say it.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@...labora.com>
> > ---
> > include/media/videobuf2-core.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/media/videobuf2-core.h
> > b/include/media/videobuf2-core.h
> > index 5ed8d3402474..20099dc22f26 100644
> > --- a/include/media/videobuf2-core.h
> > +++ b/include/media/videobuf2-core.h
> > @@ -508,6 +508,9 @@ struct vb2_buf_ops {
> >  * @last_buffer_dequeued: used in poll() and DQBUF to immediately
> > return if the
> >  *		last decoded buffer was already dequeued. Set for
> > capture queues
> >  *		when a buffer with the V4L2_BUF_FLAG_LAST is
> > dequeued.
> > + * @ordered: if the driver can guarantee that the queue will be
> > ordered or not.
> > + *		The default is not ordered unless the driver
> > sets this flag. It
> > + *		is mandatory for using explicit fences.
> 
> If it's mandatory for fences (why is that?), then I guess this patch
> should come before any of the fence implementation?

As of this implementation it is mandatory for out-fences, so that is
why I didn't put it before the in-fences support.

> 
> But it's not entirely clear to me what this flag means - ordered with
> respect to what? Ordered such that the order in which the buffers are
> queued in the driver are the same order that they will be dequeued by
> userspace?

Exactly.

> I think the order they are queued from userspace can still be
> different from both the order they are queued in the driver (because
> the in-fences can signal in any order), and dequeued again in
> userspace, so "ordered" seems a bit ambiguous.

Exactly. That is what the current implementation does.

> 
> I think it should be more clear.

Sure, sorry for not being clear, the next iteration will have a much
better explanation.

Gustavo

Powered by blists - more mailing lists