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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <573C14C3.8080604@amd.com>
Date:	Wed, 18 May 2016 09:07:47 +0200
From:	Christian König <christian.koenig@....com>
To:	Gustavo Padovan <gustavo@...ovan.org>,
	Christian König <christian.koenig@....com>,
	<dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
	Daniel Stone <daniels@...labora.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Riley Andrews <riandrews@...roid.com>,
	Rob Clark <robdclark@...il.com>,
	Greg Hackmann <ghackmann@...gle.com>,
	John Harrison <John.C.Harrison@...el.com>,
	<laurent.pinchart@...asonboard.com>, <seanpaul@...gle.com>,
	<marcheu@...gle.com>, <m.chehab@...sung.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>
Subject: Re: [RFC 1/8] dma-buf/fence: add fence_collection fences

Am 15.04.2016 um 21:25 schrieb Daniel Vetter:
> On Fri, Apr 15, 2016 at 11:27:50AM -0700, Gustavo Padovan wrote:
>> 2016-04-15 Christian König <christian.koenig@....com>:
>>> Amdgpu also has an implementation for a fence collection which uses a a
>>> hashtable to keep the fences grouped by context (e.g. only the latest fence
>>> is keept for each context). See amdgpu_sync.c for reference.
>>>
>>> We should either make the collection similar in a way that you can add as
>>> many fences as you want (like the amdgpu implementation) or make it static
>>> and only add a fixed number of fences right from the beginning.
>>>
>>> I can certainly see use cases for both, but if you want to stick with a
>>> static approach you should probably call the new object fence_array instead
>>> of fence_collection and do as Daniel suggested.
>> Maybe we can go for something in between. Have fence_collection_init()
>> need at least two fences to create the fence_collection. Then
>> fence_collection_add() would add more dinamically.
> The problem with adding fences later on is that it makes it trivial to add
> deadlocks and loops. Just add the fence collection to itself, boom. From
> that pov it's an unsafe api, and hence something to avoid.
> -Daniel

Any conclusion on this? Did any version of the patch made it upstream?

I'm in the need of an array based fence collection right now as well. 
Any objection that I just take the patch proposed here and fix the 
comments or are you still else working on this right now?

Regards,
Christian.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ