linux-kernel - Re: [PATCH v6 03/14] videobuf2: handle V4L2 buffer cache flags

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: <9ec2618b-0cce-b00e-08cf-b579d9aa1d5d@xs4all.nl>
Date:   Tue, 2 Jun 2020 12:27:39 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     Hans Verkuil <hans.verkuil@...co.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Tomasz Figa <tfiga@...omium.org>, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH v6 03/14] videobuf2: handle V4L2 buffer cache flags

On 02/06/2020 12:18, Sergey Senozhatsky wrote:
> Hi Hans,
> 
> On (20/06/02 11:51), Hans Verkuil wrote:
>> Hi Sergey,
>>
>> While doing final testing for this patch series (together with the v4l-utils patch)
>> I found one remaining issue:
> 
> Thanks for the report.
> 
>>> +static void set_buffer_cache_hints(struct vb2_queue *q,
>>> +				   struct vb2_buffer *vb,
>>> +				   struct v4l2_buffer *b)
>>> +{
>>> +	/*
>>> +	 * DMA exporter should take care of cache syncs, so we can avoid
>>> +	 * explicit ->prepare()/->finish() syncs. For other ->memory types
>>> +	 * we always need ->prepare() or/and ->finish() cache sync.
>>> +	 */
>>> +	if (q->memory == VB2_MEMORY_DMABUF) {
>>> +		vb->need_cache_sync_on_finish = 0;
>>> +		vb->need_cache_sync_on_prepare = 0;
>>> +		return;
>>> +	}
>>> +
>>> +	/*
>>> +	 * Cache sync/invalidation flags are set by default in order to
>>> +	 * preserve existing behaviour for old apps/drivers.
>>> +	 */
>>> +	vb->need_cache_sync_on_prepare = 1;
>>> +	vb->need_cache_sync_on_finish = 1;
>>> +
>>> +	if (!vb2_queue_allows_cache_hints(q)) {
>>> +		/*
>>> +		 * Clear buffer cache flags if queue does not support user
>>> +		 * space hints. That's to indicate to userspace that these
>>> +		 * flags won't work.
>>> +		 */
>>> +		b->flags &= ~V4L2_BUF_FLAG_NO_CACHE_INVALIDATE;
>>> +		b->flags &= ~V4L2_BUF_FLAG_NO_CACHE_CLEAN;
>>> +		return;
>>> +	}
>>
>> These two flags need to be cleared for VB2_MEMORY_DMABUF as well in the test above.
>> This bug is causing v4l2-compliance failures (use the test-media script in contrib/test
>> in v4l-utils: 'sudo test-media vim2m').
> 
> Sorry, Hans, do you suggest to have something like this:
> 
> 	if (q->memory == VB2_MEMORY_DMABUF) {
> 		vb->need_cache_sync_on_finish = 0;
> 		vb->need_cache_sync_on_prepare = 0;
> 		b->flags &= ~V4L2_BUF_FLAG_NO_CACHE_INVALIDATE;
> 		b->flags &= ~V4L2_BUF_FLAG_NO_CACHE_CLEAN;
> 		return;
> 	}
> 
> I didn't clear the ->flags there because we clear the vb flush/sync
> flags: ->need_cache_sync_on_finish/prepare are zeros for DMABUF memory
> type. Which is equivalent to passing V4L2_BUF_FLAG_NO_CACHE_INVALIDATE
> V4L2_BUF_FLAG_NO_CACHE_CLEAN. IOW we would clearing both "vb's do cache
> sync" and request's "do not cache sync".

Ah, yes. In that case the v4l-utils patch is likely wrong. Can you take a
look at that patch?

In any case, *something* is wrong.

Regards,

	Hans

> 
>> It's enough to post a v6.1 for this patch, everything else is fine.
> 
> Thanks!
> 
> 	-ss
>