linux-kernel - Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync

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]

Date:	Wed, 27 Jan 2016 13:41:03 -0800
From:	Greg Hackmann <ghackmann@...gle.com>
To:	Gustavo Padovan <gustavo@...ovan.org>,
	Emil Velikov <emil.l.velikov@...il.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	devel@...verdev.osuosl.org,
	ML dri-devel <dri-devel@...ts.freedesktop.org>,
	Daniel Stone <daniels@...labora.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Riley Andrews <riandrews@...roid.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Rob Clark <robdclark@...il.com>,
	John Harrison <John.C.Harrison@...el.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>
Subject: Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file

On 01/27/2016 12:25 PM, Gustavo Padovan wrote:
>>>> Is there a value in keeping the abi unchanged?
>>>> If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.
>>>
>>> None from me. I'll look where we can improve the ABI.

Android has existing clients of the current ABI.  Thankfully they're all 
contained in system services like SurfaceFlinger, since end-user apps 
don't get direct access to fence fds.

As long the ABI breaks don't remove functionality we depend on, we can 
wrap around them in our userspace libsync.  I'd rather not have to do 
that, but it's a price I'm willing to pay to get this moved out of staging.

>>   - struct sync_file_info_data::fence_info is of type __u8 yet it is "a
>> fence_info struct for every fence in the sync_file". Thus shouldn't
>> one use "struct fence_info" as the type ?
>
> Agreed. But I'm currently thinking if we really should keep this ioctl.
>
> 	Gustavo
>

I'm not seeing any consumers of driver_data in our tree.  OTOH 
completely getting rid of the ioctl would be a problem, since 
SurfaceFlinger depends on the timestamp information for its own bookkeeping.