linux-kernel - Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc

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:	Mon, 18 Jul 2016 10:15:14 -0400
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	Hans Verkuil <hverkuil@...all.nl>, linux-kernel@...r.kernel.org
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Mauro Carvalho Chehab <mchehab@...pensource.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Pawel Osciak <pawel@...iak.com>, linux-media@...r.kernel.org,
	Shuah Khan <shuahkh@....samsung.com>,
	Nicolas Dufresne <nicolas.dufresne@...labora.com>,
	Luis de Bethencourt <luisbg@....samsung.com>,
	m.olbrich@...gutronix.de
Subject: Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue
 instead of vidioc_qbuf

Hello Hans, Michael and Marek,

Thanks a lot for your feedback.

On 07/18/2016 04:34 AM, Hans Verkuil wrote:
> On 07/15/2016 06:26 PM, Javier Martinez Canillas wrote:
>> The buffer planes' dma-buf are currently mapped when buffers are queued
>> from userspace but it's more appropriate to do the mapping when buffers
>> are queued in the driver since that's when the actual DMA operation are
>> going to happen.
> 
> Does this solve anything? Once the DMA has started the behavior is the same
> as before (QBUF maps the dmabuf), only while the DMA engine hasn't started
> yet are the QBUF calls just accepted and the mapping takes place when the
> DMA is kickstarted. This makes QBUF behave inconsistently.
> 
> You don't describe here WHY this change is needed.
>

Nicolas pointed me to the TODO and suggested me the patch for the reasons
he explained in his latest email. And yes, this should had been tagged as
a RFC and just to know what you think about it. Sorry for missing that.

> I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree
> with this solution. Since queuing the buffer to the driver is not the same
> as 'just before the DMA', since there may be many buffers queued up in the
> driver and you don't know in vb2 when the buffer is at the 'just before the DMA'
> stage.
>

Right, I meant "as closer as possible to when the actual DMA is going to happen"
rather than "just before the DMA".

> Regards,
> 
> 	Hans
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America