linux-kernel - Re: [PATCH] staging/android: add flags member to sync ioctl structs

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] [day] [month] [year] [list]

Message-ID: <20160311215913.GB11274@kroah.com>
Date:	Fri, 11 Mar 2016 13:59:13 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Gustavo Padovan <gustavo@...ovan.org>, devel@...verdev.osuosl.org,
	Rob Clark <robdclark@...il.com>,
	Daniel Stone <daniels@...labora.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Riley Andrews <riandrews@...roid.com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Arve Hjønnevåg <arve@...roid.com>,
	Greg Hackmann <ghackmann@...gle.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [PATCH] staging/android: add flags member to sync ioctl structs

On Fri, Mar 04, 2016 at 05:40:29PM +0100, Daniel Vetter wrote:
> On Thu, Mar 03, 2016 at 08:17:14AM -0800, Greg Kroah-Hartman wrote:
> > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
> > > 
> > > Play safe and add flags member to all structs. So we don't need to
> > > break API or create new IOCTL in the future if new features that requires
> > > flags arises.
> > > 
> > > v2: check if flags are valid (zero, in this case)
> > > 
> > > v3: return -EINVAL if flags are not zero'ed
> > > 
> > > v4: add padding for 64-bit alignment
> > > 
> > > v5: rebase to use only stacked sync_file_info
> > 
> > Why are these vX things here in the changelog?
> 
> Because this is drm and we're special ;-)
> 
> > And you just broke all existing userspace users of this code, why are
> > you allowed to do that?
> > 
> > not ok...
> 
> We could do fence2.h if you absolutely insist and just forget about the
> current one, but that seemed silly. Like Gustavo said, everyone who
> actually cares about this stuff is perfectly fine with this. And there's
> not a single user of this in upstream anyway, so the only trees we could
> break are vendor trees with massive amounts of additional stuff.
> 
> Is that reasonable ok for you, or do you insist we do a fences2.h without
> going through staging ? ;-)

Ok, if everyone is ok with this api changing, and will not get mad if it
breaks things, I'm all for fixing this up.

I just want all of your signed-off-by lines on the series please.
Please respond to the v7 of this series and I'll be glad to queue them
up.

thanks,

greg k-h