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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 29 Jan 2016 09:46:15 -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>,
	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/28/16 01:23, Daniel Vetter wrote:
> And I think driver_data really shouldn't be there, it makes things
> complicated with the array of variable-sized objects, and generic
> userspace can't really use it - for debug output we already have
> obj/driver_name per fence point, which I think is good enough.

I looked at our device kernels, and some vendors actually are filling in 
driver_data.  I'm just not seeing any accesses to them in our 
*userspace* tree.  And in a lot of cases it looks like they're just 
filling in debugging information that they could get elsewhere.

I'm checking with our vendor contacts to see what they're actually using 
this for (if anything).

> Would that be ok for you from the Android side if Gustavo also provides a
> patch to update libsync? I don't think the ABI is fundamentally broken,
> but this light cleanup would be nice.

No objections here.  Just upload the changes to AOSP and add me as a 
reviewer.

> Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since
> polling is supported, but not really an issue imo either. If we're totally
> lazy we could implement SYNC_WAIT internally using poll and shave off a
> few lines of the implementation.

Honestly this is the change I'm least worried about, since poll() will 
work with existing kernels too.  The only difference would be that the 
SYNC_WAIT ioctl fails when given something that's not specifically a 
sync fence; but I'm skeptical that anything actually depends on that 
behavior.