staging/android: change IOCTLs opcode after ABI change

Commit Message

Gustavo Padovan March 3, 2016, 10:42 p.m. UTC

From: Gustavo Padovan <[e-mail]>

Burn the old opcode to avoid any potential old userspace running the old
API to get weird errors. Changing the opcodes will make them fail right
away.

This is just a precaution, there no upstream users of these interfaces
yet and the only user is Android, but we don't expect anyone trying to
run android userspace and all it dependencies on top of upstream kernels.

Moreover Android should be converted to use upstream sync_files.

Suggested-by: Rob Clark <[e-mail]>
Signed-off-by: Gustavo Padovan <[e-mail]>
---
 drivers/staging/android/uapi/sync.h | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

Comments

Greg Hackmann March 9, 2016, 2:36 a.m. UTC | #1

On 03/03/2016 02:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan <[e-mail]>
>
> Burn the old opcode to avoid any potential old userspace running the old
> API to get weird errors. Changing the opcodes will make them fail right
> away.
>
> This is just a precaution, there no upstream users of these interfaces
> yet and the only user is Android, but we don't expect anyone trying to
> run android userspace and all it dependencies on top of upstream kernels.
>
> Moreover Android should be converted to use upstream sync_files.
>
> Suggested-by: Rob Clark <[e-mail]>
> Signed-off-by: Gustavo Padovan <[e-mail]>

Acked-by: Greg Hackmann <[e-mail]>

Greg KH March 11, 2016, 10 p.m. UTC | #2

On Thu, Mar 03, 2016 at 07:42:43PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan <[e-mail]>
> 
> Burn the old opcode to avoid any potential old userspace running the old
> API to get weird errors. Changing the opcodes will make them fail right
> away.
> 
> This is just a precaution, there no upstream users of these interfaces
> yet and the only user is Android, but we don't expect anyone trying to
> run android userspace and all it dependencies on top of upstream kernels.
> 
> Moreover Android should be converted to use upstream sync_files.
> 
> Suggested-by: Rob Clark <[e-mail]>
> Signed-off-by: Gustavo Padovan <[e-mail]>
> ---
>  drivers/staging/android/uapi/sync.h | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)

Where does this belong in this patch series?  Before it?  After it?  In
the middle?

Please resend the whole series, gather up all of the reviewed and
signed-off-by markings from everyone involved, and I'll be glad to apply
them.

thanks,

greg k-h

Rob Clark March 12, 2016, 5:34 p.m. UTC | #3

On Fri, Mar 11, 2016 at 5:00 PM, Greg Kroah-Hartman
<[e-mail]> wrote:
> On Thu, Mar 03, 2016 at 07:42:43PM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan <[e-mail]>
>>
>> Burn the old opcode to avoid any potential old userspace running the old
>> API to get weird errors. Changing the opcodes will make them fail right
>> away.
>>
>> This is just a precaution, there no upstream users of these interfaces
>> yet and the only user is Android, but we don't expect anyone trying to
>> run android userspace and all it dependencies on top of upstream kernels.
>>
>> Moreover Android should be converted to use upstream sync_files.
>>
>> Suggested-by: Rob Clark <[e-mail]>
>> Signed-off-by: Gustavo Padovan <[e-mail]>
>> ---
>>  drivers/staging/android/uapi/sync.h | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> Where does this belong in this patch series?  Before it?  After it?  In
> the middle?

Not sure if overkill, but if we wanted to be pedantic about
bisectability put all the uabi struct changes plus ioctl # changes
into a single patch (with the following patches starting to use the
new fields)?

Either way, I think the only two people in the world effected by this
(ie. who are playing with AOSP on an upstream (plus a few patches)
kernel) are Rob Herring and John Stultz.  (Adding them to CC so they
are aware).

BR,
-R

> Please resend the whole series, gather up all of the reviewed and
> signed-off-by markings from everyone involved, and I'll be glad to apply
> them.
>
> thanks,
>
> greg k-h

Patch

diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index 859977c..fbadb8a 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -69,13 +69,20 @@  struct sync_file_info {
 #define SYNC_IOC_MAGIC		'>'
 
 /**
+ * Opcodes  0, 1 and 2 were burned during a API change to avoid users of the
+ * old API to get weird errors when trying to handling sync_files. The API
+ * change happened during the de-stage of the Sync Framework when there was
+ * no upstream users available.
+ */
+
+/**
  * DOC: SYNC_IOC_MERGE - merge two fences
  *
  * Takes a struct sync_merge_data.  Creates a new fence containing copies of
  * the sync_pts in both the calling fd and sync_merge_data.fd2.  Returns the
  * new fence's fd in sync_merge_data.fence
  */
-#define SYNC_IOC_MERGE		_IOWR(SYNC_IOC_MAGIC, 1, struct sync_merge_data)
+#define SYNC_IOC_MERGE		_IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
 
 /**
  * DOC: SYNC_IOC_FENCE_INFO - get detailed information on a fence
@@ -88,6 +95,6 @@  struct sync_file_info {
  * pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
  * To iterate over the sync_pt_infos, use the sync_pt_info.len field.
  */
-#define SYNC_IOC_FILE_INFO	_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO	_IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
 
 #endif /* _UAPI_LINUX_SYNC_H */