[PATCH] staging/android: add flags member to sync ioctl structs

[Greg Kroah-Hartman]

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 
> > > 
> > > 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

[PATCH] staging/android: add flags member to sync ioctl structs

[Emil Velikov]

Hi Greg,

Allow me to chip in as well.

On 3 March 2016 at 16:17, Greg Kroah-Hartman  
wrote:
> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> 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

[PATCH] staging/android: add flags member to sync ioctl structs

[Daniel Vetter]

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 
> > 
> > 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 ? ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] staging/android: add flags member to sync ioctl structs

[Ville Syrjälä]

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 
> > 
> > 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?

That's how we usually roll in gpu land.

-- 
Ville Syrjälä
Intel OTC

[PATCH] staging/android: add flags member to sync ioctl structs

[Rob Clark]

On Thu, Mar 3, 2016 at 3:54 PM, Rob Clark  wrote:
> On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman
>  wrote:
>> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>>> From: Gustavo Padovan 
>>>
>>> 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

[PATCH] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

2016-03-03 Gustavo Padovan :

> Hi Greg,
> 
> 2016-03-03 Greg Kroah-Hartman :
> 
> > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan 
> > > 
> > > 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?
> 
> There are few people who does this in drm, so I just followed that.  

Anyway, I've sent v7 without the vX things in the changelog.

Gustavo

[PATCH] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

Hi Greg,

2016-03-03 Greg Kroah-Hartman :

> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > 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?

There are few people who does this in drm, so I just followed that.  

> 
> And you just broke all existing userspace users of this code, why are
> you allowed to do that?

Because we've discussed this extensively in the last versions of this
patches. Most of the people from CC agreed with it.

We are cleaning up the Android sync and coming up with a better ABI for
it before we de-stage it. Android people agreed with this and we will
patch it.

Gustavo

[PATCH] staging/android: add flags member to sync ioctl structs

[Rob Clark]

On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman
 wrote:
> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> 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.)

BR,
-R

[PATCH] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

From: Gustavo Padovan 

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

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  |  8 
 drivers/staging/android/uapi/sync.h | 14 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 48ee175..ae81c95 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags || data.pad) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (copy_from_user(, (void __user *)arg, sizeof(info)))
return -EFAULT;

+   if (info.flags || info.pad)
+   return -EINVAL;
+
/*
 * Passing num_fences = 0 means that userspace doesn't want to
 * retrieve any sync_fence_info. If num_fences = 0 we skip filling
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a122bb5..859977c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,14 +16,18 @@

 /**
  * struct sync_merge_data - data passed to merge ioctl
- * @fd2:   file descriptor of second fence
  * @name:  name of new fence
+ * @fd2:   file descriptor of second fence
  * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad:   padding for 64-bit alignment, should always be zero
  */
 struct sync_merge_data {
-   __s32   fd2;
charname[32];
+   __s32   fd2;
__s32   fence;
+   __u32   flags;
+   __u32   pad;
 };

 /**
@@ -31,12 +35,14 @@ struct sync_merge_data {
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32   status;
+   __u32   flags;
__u64   timestamp_ns;
 };

@@ -44,14 +50,18 @@ struct sync_fence_info {
  * struct sync_file_info - data returned from fence info ioctl
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
+ * @pad:   padding for 64-bit alignment, should always be zero
  * @sync_fence_info: pointer to array of structs sync_fence_info with all
  *  fences in the sync_file
  */
 struct sync_file_info {
charname[32];
__s32   status;
+   __u32   flags;
__u32   num_fences;
+   __u32   pad;

__u64   sync_fence_info;
 };
-- 
2.5.0

[PATCH] staging/android: add flags member to sync ioctl structs

[Greg Kroah-Hartman]

On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> 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...

[PATCH] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

From: Gustavo Padovan 

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

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  |  8 
 drivers/staging/android/uapi/sync.h | 14 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3604e453..0196d3d 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags || data.pad) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (copy_from_user(, (void __user *)arg, sizeof(in)))
return -EFAULT;

+   if (in.flags || in.pad)
+   return -EINVAL;
+
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a122bb5..859977c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,14 +16,18 @@

 /**
  * struct sync_merge_data - data passed to merge ioctl
- * @fd2:   file descriptor of second fence
  * @name:  name of new fence
+ * @fd2:   file descriptor of second fence
  * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad:   padding for 64-bit alignment, should always be zero
  */
 struct sync_merge_data {
-   __s32   fd2;
charname[32];
+   __s32   fd2;
__s32   fence;
+   __u32   flags;
+   __u32   pad;
 };

 /**
@@ -31,12 +35,14 @@ struct sync_merge_data {
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32   status;
+   __u32   flags;
__u64   timestamp_ns;
 };

@@ -44,14 +50,18 @@ struct sync_fence_info {
  * struct sync_file_info - data returned from fence info ioctl
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
+ * @pad:   padding for 64-bit alignment, should always be zero
  * @sync_fence_info: pointer to array of structs sync_fence_info with all
  *  fences in the sync_file
  */
 struct sync_file_info {
charname[32];
__s32   status;
+   __u32   flags;
__u32   num_fences;
+   __u32   pad;

__u64   sync_fence_info;
 };
-- 
2.5.0