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
| ||
|
Date: Thu, 23 Jan 2020 12:35:33 +0100 From: Hans Verkuil <hverkuil@...all.nl> To: Sergey Senozhatsky <senozhatsky@...omium.org> Cc: Hans Verkuil <hans.verkuil@...co.com>, Tomasz Figa <tfiga@...omium.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, Kyungmin Park <kyungmin.park@...sung.com>, Marek Szyprowski <m.szyprowski@...sung.com>, Sakari Ailus <sakari.ailus@....fi>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, Pawel Osciak <posciak@...omium.org>, linux-media@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC][PATCH 13/15] videobuf2: do not sync buffers for DMABUF queues On 1/22/20 6:05 AM, Sergey Senozhatsky wrote: > On (20/01/10 11:30), Hans Verkuil wrote: > [..] >>> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c >>> index 1762849288ae..2b9d3318e6fb 100644 >>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c >>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c >>> @@ -341,8 +341,22 @@ static void set_buffer_cache_hints(struct vb2_queue *q, >>> struct vb2_buffer *vb, >>> struct v4l2_buffer *b) >>> { >>> - vb->need_cache_sync_on_prepare = 1; >>> + /* >>> + * DMA exporter should take care of cache syncs, so we can avoid >>> + * explicit ->prepare()/->finish() syncs. >>> + */ >>> + if (q->memory == VB2_MEMORY_DMABUF) { >>> + vb->need_cache_sync_on_finish = 0; >>> + vb->need_cache_sync_on_prepare = 0; >>> + return; >>> + } >>> >>> + /* >>> + * For other ->memory types we always need ->prepare() cache >>> + * sync. ->finish() cache sync, however, can be avoided when queue >>> + * direction is TO_DEVICE. >>> + */ >>> + vb->need_cache_sync_on_prepare = 1; >> >> I'm trying to remember: what needs to be done in prepare() >> for a capture buffer? I thought that for capture you only >> needed to invalidate the cache in finish(), but nothing needs >> to be done in the prepare(). > > Hmm. Not sure. A precaution in case if user-space wrote to that buffer? But whatever was written in the buffer is going to be overwritten anyway. Unless I am mistaken the current situation is that the cache syncs are done in both prepare and finish, regardless of the DMA direction. I would keep that behavior to avoid introducing any unexpected regressions. Then, if q->allow_cache_hint is set, then default to a cache sync (cache clean) in the prepare for OUTPUT buffers and a cache sync (cache invalidate) in the finish for CAPTURE buffers. This also means that any drivers that want to access a buffer in between the prepare...finish calls will need to do a begin/end_cpu_access. But that's a separate matter. Regards, Hans > > + if (q->dma_dir == DMA_FROM_DEVICE) > + q->need_cache_sync_on_prepare = 0; > > ? > > -ss >
Powered by blists - more mailing lists