linux-kernel - Re: [PATCH v3] media: docs-rst: Document m2m stateless video decoder interface

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: <b24e3e67-9fb3-3602-8a90-826f8c51eadf@xs4all.nl>
Date:   Wed, 13 Feb 2019 09:59:40 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Alexandre Courbot <acourbot@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Pawel Osciak <posciak@...omium.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] media: docs-rst: Document m2m stateless video decoder
 interface

On 2/13/19 6:58 AM, Alexandre Courbot wrote:
> On Wed, Feb 13, 2019 at 2:53 PM Alexandre Courbot <acourbot@...omium.org> wrote:
>> [snip]
>> +Buffers used as reference frames can be queued back to the ``CAPTURE`` queue as
>> +soon as all the frames they are affecting have been queued to the ``OUTPUT``
>> +queue. The driver will refrain from using the reference buffer as a decoding
>> +target until all the frames depending on it are decoded.
> 
> Just want to highlight this part in order to make sure that this is
> indeed what we agreed on. The recent changes to vb2_find_timestamp()
> suggest this, but maybe I misunderstood the intent. It makes the
> kernel responsible for tracking referenced buffers and not using them
> until all the dependent frames are decoded, something the client could
> also do.

I don't think this is quite right. Once this patch https://patchwork.linuxtv.org/patch/54275/
is in the vb2 core will track when a buffer can no longer be used as a
reference buffer because the underlying memory might have disappeared.

The core does not check if it makes sense to use a buffer as a reference
frame, just that it is valid memory.

So the driver has to check that the timestamp refers to an existing
buffer, but userspace has to check that it queues everything in the
right order and that the reference buffer won't be overwritten
before the last output buffer using that reference buffer has been
decoded.

So I would say that the second sentence in your paragraph is wrong.

The first sentence isn't quite right either, but I am not really sure how
to phrase it. It is possible to queue a reference buffer even if
not all output buffers referring to it have been decoded, provided
that by the time the driver starts to use this buffer this actually
has happened.

But this is an optimization and theoretically it can depend on the
driver behavior. It is always safe to only queue a reference frame
when all frames depending on it have been decoded. So I am leaning
towards not complicating matters and keeping your first sentence
as-is.

Regards,

	Hans