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: <CACvgo525dTOYD=hNqnai2D0h3QU2ukCC694RqUNS_PBz9vxkig@mail.gmail.com>
Date:	Sat, 5 Mar 2016 12:58:58 +0000
From:	Emil Velikov <emil.l.velikov@...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>,
	Riley Andrews <riandrews@...roid.com>,
	ML dri-devel <dri-devel@...ts.freedesktop.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.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

Hi Greg,

Allow me to chip in as well.

On 3 March 2016 at 16:17, 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?
>
In all honesty, isn't 'fluid ABI' one of the reasons behind staging ?
That is how it was used by a few drivers in the past, at least. If the
rules have changed and/or Android is special in that regard, we ought
to make it perfectly clear so that people are aware from day 1.

That aside, Android developers were clear that only internal,
downstream components are using this code and they are OK with
breaking the ABI [1]. Gustavo is in the process of rewriting their
tests for upstream inclusion and he'll also update the Android side of
things [2].

With those in mind, I think everything should be safe here. If you
prefer to avoid the ABI break, which approach are you keen on -
reassign new ioctl numbers (Rob suggestion) or use new header fence2.h
(Daniel).

Thank you
Emil

[1] https://lists.freedesktop.org/archives/dri-devel/2016-January/099592.html
[2] https://lists.freedesktop.org/archives/dri-devel/2016-January/099726.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ