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

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

Date:	Thu, 3 Mar 2016 16:47:34 -0500
From:	Rob Clark <robdclark@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Gustavo Padovan <gustavo@...ovan.org>, devel@...verdev.osuosl.org,
	Daniel Stone <daniels@...labora.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Riley Andrews <riandrews@...roid.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <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 Thu, Mar 3, 2016 at 3:54 PM, Rob Clark <robdclark@...il.com> wrote:
> On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> 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?
>>
>> And you just broke all existing userspace users of this code, why are
>> you allowed to do that?
>>
>> not ok...
>
> There are not really any users of this on an upstream kernel yet, so
> it makes sense to fix the ABI to something we can live with now,
> before that changes.  If we are stuck not breaking ABI with android
> stuff pulled into staging as we destage it, then maybe we should be a
> *lot* slower at pulling android stuff into staging.  (Ie. if that is
> the case, please kick it all out now and we'll re-add things
> properly.)

That all said, I suppose one sensible concession to practicality would
be to burn the old ioctl numbers and pick new ioctl numbers.  At least
this way if someone did manage to take an old android userspace (with
it's various dependencies on other non-upstream SoC specific platform
drivers, etc) and run it on upstream kernel, at least things would
fail in an obvious way.  I could live with this as the
mode-of-operations for fixing up and destaging staging/android stuff.

BR,
-R