[PATCH v6 1/6] staging/android: add num_fences field to struct sync_file_info

[PATCH v6 1/6] staging/android: add num_fences field to struct sync_file_info

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Inform userspace how many fences are in the sync_fence_info field.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
 drivers/staging/android/sync.c      | 2 ++
 drivers/staging/android/uapi/sync.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..31aa462 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,6 +525,8 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 	if (info->status >= 0)
 		info->status = !info->status;
 
+	info->num_fences = sync_file->num_fences;
+
 	len = sizeof(struct sync_file_info);
 
 	for (i = 0; i < sync_file->num_fences; ++i) {
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index a0cf357..4ffb7cc 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -47,12 +47,14 @@ struct sync_fence_info {
  *		userspace including pt_info.
  * @name:	name of fence
  * @status:	status of fence. 1: signaled 0:active <0:error
+ * @num_fences	number of fences in the sync_file
  * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
  */
 struct sync_file_info {
 	__u32	len;
 	char	name[32];
 	__s32	status;
+	__u32	num_fences;
 
 	__u8	sync_fence_info[0];
 };
-- 
2.5.0

[PATCH v6 2/6] staging/android: rename SYNC_IOC_FENCE_INFO

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

We don't use the 'fence' name to refer to sync_file anymore. So rename it
to SYNC_IOC_FILE_INFO.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
 drivers/staging/android/sync.c      | 2 +-
 drivers/staging/android/uapi/sync.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 31aa462..dc5f382 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -562,7 +562,7 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd,
 	case SYNC_IOC_MERGE:
 		return sync_file_ioctl_merge(sync_file, arg);
 
-	case SYNC_IOC_FENCE_INFO:
+	case SYNC_IOC_FILE_INFO:
 		return sync_file_ioctl_fence_info(sync_file, arg);
 
 	default:
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index 4ffb7cc..dd0dd84 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -81,6 +81,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_FENCE_INFO	_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO	_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
 
 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 3/6] staging/android: remove redundant comments on sync_merge_data

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index dd0dd84..f0b41ce 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
  * @fence:	returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-	__s32	fd2; /* fd of second fence */
-	char	name[32]; /* name of new fence */
-	__s32	fence; /* fd on newly created fence */
+	__s32	fd2;
+	char	name[32];
+	__s32	fence;
 };
 
 /**
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 4/6] staging/android: align struct sync_merge_data to a multiple of 64-bits

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Change order of the field to avoid alignment issues with 64 bits
platforms.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/staging/android/uapi/sync.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index f0b41ce..a6c648c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,13 +16,13 @@
 
 /**
  * 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
  */
 struct sync_merge_data {
-	__s32	fd2;
 	char	name[32];
+	__s32	fd2;
 	__s32	fence;
 };
 
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/6] staging/android: align struct sync_merge_data to a multiple of 64-bits

[Gustavo Padovan]

2016-03-02 Gustavo Padovan <gustavo@padovan.org>:

> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> 
> Change order of the field to avoid alignment issues with 64 bits
> platforms.
> 
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
>  drivers/staging/android/uapi/sync.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Please ignore this patch, it is not really needed.

	Gustavo

[PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer

Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.

However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.

Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.

Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.

Also, info->sync_fence_info was converted to __u64 pointer to prevent
32bit compatibility issues.

An example userspace code for the later would be:

	struct sync_file_info *info;
	int err, size, num_fences;

	info = malloc(sizeof(*info));

	info.flags = 0;
	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	num_fences = info->num_fences;

	if (num_fences) {
		info.flags = 0;
		size = sizeof(struct sync_fence_info) * num_fences;
		info->num_fences = num_fences;
		info->sync_fence_info = (uint64_t) calloc(num_fences,
							  sizeof(struct sync_fence_info));

		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	}

v2: fix fence_info memory leak

v3: Comments from Emil Velikov
	- improve commit message
	- remove __u64 cast
	- remove check for output fields in file_info
	- clean up sync_fill_fence_info()

    Comments from Maarten Lankhorst
	- remove in.num_fences && !in.sync_fence_info check
	- remove info->len and use only num_fences to calculate size

    Comments from Dan Carpenter
	- fix info->sync_fence_info documentation

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/staging/android/sync.c      | 64 ++++++++++++++++++++-----------------
 drivers/staging/android/uapi/sync.h |  9 ++----
 2 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..3604e453 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -479,13 +479,9 @@ err_put_fd:
 	return err;
 }
 
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+				struct sync_fence_info *info)
 {
-	struct sync_fence_info *info = data;
-
-	if (size < sizeof(*info))
-		return -ENOMEM;
-
 	strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
 		sizeof(info->obj_name));
 	strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,28 +491,20 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
 	else
 		info->status = 0;
 	info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
-	return sizeof(*info);
 }
 
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 					unsigned long arg)
 {
-	struct sync_file_info *info;
+	struct sync_file_info in, *info;
+	struct sync_fence_info *fence_info = NULL;
 	__u32 size;
-	__u32 len = 0;
 	int ret, i;
 
-	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+	if (copy_from_user(&in, (void __user *)arg, sizeof(in)))
 		return -EFAULT;
 
-	if (size < sizeof(struct sync_file_info))
-		return -EINVAL;
-
-	if (size > 4096)
-		size = 4096;
-
-	info = kzalloc(size, GFP_KERNEL);
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
 	if (!info)
 		return -ENOMEM;
 
@@ -525,29 +513,47 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 	if (info->status >= 0)
 		info->status = !info->status;
 
-	info->num_fences = sync_file->num_fences;
-
-	len = sizeof(struct sync_file_info);
+	/*
+	 * Passing num_fences = 0 means that userspace doesn't want to
+	 * retrieve any sync_fence_info. If num_fences = 0 we skip filling
+	 * sync_fence_info and return the actual number of fences on
+	 * info->num_fences.
+	 */
+	if (!in.num_fences)
+		goto no_fences;
 
-	for (i = 0; i < sync_file->num_fences; ++i) {
-		struct fence *fence = sync_file->cbs[i].fence;
+	if (in.num_fences < sync_file->num_fences) {
+		ret = -EINVAL;
+		goto out;
+	}
 
-		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+	size = sync_file->num_fences * sizeof(*fence_info);
+	fence_info = kzalloc(size, GFP_KERNEL);
+	if (!fence_info) {
+		ret = -ENOMEM;
+		goto out;
+	}
 
-		if (ret < 0)
-			goto out;
+	for (i = 0; i < sync_file->num_fences; ++i)
+		sync_fill_fence_info(sync_file->cbs[i].fence, &fence_info[i]);
 
-		len += ret;
+	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
+		ret = -EFAULT;
+		goto out;
 	}
 
-	info->len = len;
+	info->sync_fence_info = in.sync_fence_info;
+
+no_fences:
+	info->num_fences = sync_file->num_fences;
 
-	if (copy_to_user((void __user *)arg, info, len))
+	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
 		ret = -EFAULT;
 	else
 		ret = 0;
 
 out:
+	kfree(fence_info);
 	kfree(info);
 
 	return ret;
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index a6c648c..f064923 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -42,21 +42,18 @@ struct sync_fence_info {
 
 /**
  * struct sync_file_info - data returned from fence info ioctl
- * @len:	ioctl caller writes the size of the buffer its passing in.
- *		ioctl returns length of sync_file_info returned to
- *		userspace including pt_info.
  * @name:	name of fence
  * @status:	status of fence. 1: signaled 0:active <0:error
  * @num_fences	number of fences in the sync_file
- * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
+ * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ *		 fences in the sync_file
  */
 struct sync_file_info {
-	__u32	len;
 	char	name[32];
 	__s32	status;
 	__u32	num_fences;
 
-	__u8	sync_fence_info[0];
+	__u64	sync_fence_info;
 };
 
 #define SYNC_IOC_MAGIC		'>'
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO

[Maarten Lankhorst]

Op 02-03-16 om 20:52 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed is greater
> than zero info->sync_fence_info should point to a buffer with enough space
> to fit all fences.
>
> However if num_fences passed to the kernel is 0, the kernel will reply
> with number of fences of the sync_file.
>
> Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
> in a first call with num_fences = 0 userspace will receive the actual
> number of fences in the num_fences filed.
>
> Then it can allocate a buffer with the correct size on sync_fence_info and
> call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
> in the sync_file.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
>
> An example userspace code for the later would be:
>
> 	struct sync_file_info *info;
> 	int err, size, num_fences;
>
> 	info = malloc(sizeof(*info));
>
> 	info.flags = 0;
> 	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> 	num_fences = info->num_fences;
>
> 	if (num_fences) {
> 		info.flags = 0;
> 		size = sizeof(struct sync_fence_info) * num_fences;
> 		info->num_fences = num_fences;
> 		info->sync_fence_info = (uint64_t) calloc(num_fences,
> 							  sizeof(struct sync_fence_info));
>
> 		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> 	}
>
> v2: fix fence_info memory leak
>
> v3: Comments from Emil Velikov
> 	- improve commit message
> 	- remove __u64 cast
> 	- remove check for output fields in file_info
> 	- clean up sync_fill_fence_info()
>
>     Comments from Maarten Lankhorst
> 	- remove in.num_fences && !in.sync_fence_info check
> 	- remove info->len and use only num_fences to calculate size
>
>     Comments from Dan Carpenter
> 	- fix info->sync_fence_info documentation
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
>  drivers/staging/android/sync.c      | 64 ++++++++++++++++++++-----------------
>  drivers/staging/android/uapi/sync.h |  9 ++----
>  2 files changed, 38 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..3604e453 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -479,13 +479,9 @@ err_put_fd:
>  	return err;
>  }
>  
> -static int sync_fill_fence_info(struct fence *fence, void *data, int size)
> +static void sync_fill_fence_info(struct fence *fence,
> +				struct sync_fence_info *info)
>  {
> -	struct sync_fence_info *info = data;
> -
> -	if (size < sizeof(*info))
> -		return -ENOMEM;
> -
>  	strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
>  		sizeof(info->obj_name));
>  	strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
> @@ -495,28 +491,20 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
>  	else
>  		info->status = 0;
>  	info->timestamp_ns = ktime_to_ns(fence->timestamp);
> -
> -	return sizeof(*info);
>  }
>  
>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>  					unsigned long arg)
>  {
> -	struct sync_file_info *info;
> +	struct sync_file_info in, *info;
Why put one copy on the stack, and allocate a second?
With sync_file_info now being a fixed size just put 1 copy on the stack from userspace,
run some sanity checks first, put in the new values and copy it back to userspace without additional memory allocation.

The rest looks good now. :)

~Maarten

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer

Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.

However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.

Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.

Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.

Also, info->sync_fence_info was converted to __u64 pointer to prevent
32bit compatibility issues.

An example userspace code for the later would be:

	struct sync_file_info *info;
	int err, size, num_fences;

	info = malloc(sizeof(*info));

	info.flags = 0;
	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	num_fences = info->num_fences;

	if (num_fences) {
		info.flags = 0;
		size = sizeof(struct sync_fence_info) * num_fences;
		info->num_fences = num_fences;
		info->sync_fence_info = (uint64_t) calloc(num_fences,
							  sizeof(struct sync_fence_info));

		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	}

v2: fix fence_info memory leak

v3: Comments from Emil Velikov
	- improve commit message
	- remove __u64 cast
	- remove check for output fields in file_info
	- clean up sync_fill_fence_info()

    Comments from Maarten Lankhorst
	- remove in.num_fences && !in.sync_fence_info check
	- remove info->len and use only num_fences to calculate size

    Comments from Dan Carpenter
	- fix info->sync_fence_info documentation

v4: remove allocated struct sync_file_info (comment from Maarten)

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/staging/android/sync.c      | 70 +++++++++++++++++--------------------
 drivers/staging/android/uapi/sync.h |  9 ++---
 2 files changed, 36 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..48ee175 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -479,13 +479,9 @@ err_put_fd:
 	return err;
 }
 
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+				struct sync_fence_info *info)
 {
-	struct sync_fence_info *info = data;
-
-	if (size < sizeof(*info))
-		return -ENOMEM;
-
 	strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
 		sizeof(info->obj_name));
 	strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,60 +491,60 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
 	else
 		info->status = 0;
 	info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
-	return sizeof(*info);
 }
 
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 					unsigned long arg)
 {
-	struct sync_file_info *info;
+	struct sync_file_info info;
+	struct sync_fence_info *fence_info = NULL;
 	__u32 size;
-	__u32 len = 0;
 	int ret, i;
 
-	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+	if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
 		return -EFAULT;
 
-	if (size < sizeof(struct sync_file_info))
-		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
+	 * sync_fence_info and return the actual number of fences on
+	 * info->num_fences.
+	 */
+	if (!info.num_fences)
+		goto no_fences;
 
-	if (size > 4096)
-		size = 4096;
+	if (info.num_fences < sync_file->num_fences)
+		return -EINVAL;
 
-	info = kzalloc(size, GFP_KERNEL);
-	if (!info)
+	size = sync_file->num_fences * sizeof(*fence_info);
+	fence_info = kzalloc(size, GFP_KERNEL);
+	if (!fence_info)
 		return -ENOMEM;
 
-	strlcpy(info->name, sync_file->name, sizeof(info->name));
-	info->status = atomic_read(&sync_file->status);
-	if (info->status >= 0)
-		info->status = !info->status;
+	for (i = 0; i < sync_file->num_fences; ++i)
+		sync_fill_fence_info(sync_file->cbs[i].fence, &fence_info[i]);
 
-	info->num_fences = sync_file->num_fences;
-
-	len = sizeof(struct sync_file_info);
-
-	for (i = 0; i < sync_file->num_fences; ++i) {
-		struct fence *fence = sync_file->cbs[i].fence;
-
-		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
-
-		if (ret < 0)
-			goto out;
-
-		len += ret;
+	if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
+			 size)) {
+		ret = -EFAULT;
+		goto out;
 	}
 
-	info->len = len;
+no_fences:
+	strlcpy(info.name, sync_file->name, sizeof(info.name));
+	info.status = atomic_read(&sync_file->status);
+	if (info.status >= 0)
+		info.status = !info.status;
+
+	info.num_fences = sync_file->num_fences;
 
-	if (copy_to_user((void __user *)arg, info, len))
+	if (copy_to_user((void __user *)arg, &info, sizeof(info)))
 		ret = -EFAULT;
 	else
 		ret = 0;
 
 out:
-	kfree(info);
+	kfree(fence_info);
 
 	return ret;
 }
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index f0b41ce..a122bb5 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -42,21 +42,18 @@ struct sync_fence_info {
 
 /**
  * struct sync_file_info - data returned from fence info ioctl
- * @len:	ioctl caller writes the size of the buffer its passing in.
- *		ioctl returns length of sync_file_info returned to
- *		userspace including pt_info.
  * @name:	name of fence
  * @status:	status of fence. 1: signaled 0:active <0:error
  * @num_fences	number of fences in the sync_file
- * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
+ * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ *		 fences in the sync_file
  */
 struct sync_file_info {
-	__u32	len;
 	char	name[32];
 	__s32	status;
 	__u32	num_fences;
 
-	__u8	sync_fence_info[0];
+	__u64	sync_fence_info;
 };
 
 #define SYNC_IOC_MAGIC		'>'
-- 
2.5.0

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Maarten Lankhorst]

Op 03-03-16 om 15:34 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed is greater
> than zero info->sync_fence_info should point to a buffer with enough space
> to fit all fences.
>
> However if num_fences passed to the kernel is 0, the kernel will reply
> with number of fences of the sync_file.
>
> Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
> in a first call with num_fences = 0 userspace will receive the actual
> number of fences in the num_fences filed.
>
> Then it can allocate a buffer with the correct size on sync_fence_info and
> call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
> in the sync_file.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
For this patch and 6/6:

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.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

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/staging/android/sync.c      | 8 ++++++++
 drivers/staging/android/uapi/sync.h | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3604e453..e635e6e 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) {
+		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(&in, (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 f064923..4b4d079 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -19,11 +19,13 @@
  * @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
  */
 struct sync_merge_data {
 	char	name[32];
 	__s32	fd2;
 	__s32	fence;
+	__u32	flags;
 };
 
 /**
@@ -31,12 +33,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 {
 	char	obj_name[32];
 	char	driver_name[32];
 	__s32	status;
+	__u32	flags;
 	__u64	timestamp_ns;
 };
 
@@ -44,14 +48,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 {
 	char	name[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

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.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

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 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(&in, (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;
 	char	name[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 {
 	char	obj_name[32];
 	char	driver_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 {
 	char	name[32];
 	__s32	status;
+	__u32	flags;
 	__u32	num_fences;
+	__u32	pad;
 
 	__u64	sync_fence_info;
 };
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.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

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 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(&info, (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;
 	char	name[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 {
 	char	obj_name[32];
 	char	driver_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 {
 	char	name[32];
 	__s32	status;
+	__u32	flags;
 	__u32	num_fences;
+	__u32	pad;
 
 	__u64	sync_fence_info;
 };
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 <gustavo.padovan@collabora.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...

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Gustavo Padovan]

Hi Greg,

2016-03-03 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:

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

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

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

[Gustavo Padovan]

2016-03-03 Gustavo Padovan <gustavo.padovan@collabora.co.uk>:

> Hi Greg,
> 
> 2016-03-03 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> 
> > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@collabora.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?
> 
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 <gustavo.padovan@collabora.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?

That's how we usually roll in gpu land.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

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

BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Thu, Mar 3, 2016 at 3:54 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Mar 3, 2016 at 11:17 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>>> From: Gustavo Padovan <gustavo.padovan@collabora.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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 <gustavo.padovan@collabora.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 ? ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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 <gustavo.padovan@collabora.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

Re: [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 <gregkh@linuxfoundation.org> wrote:
> On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan <gustavo.padovan@collabora.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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 4/5] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer allocation. In the new approach the ioctl needs to be called
twice to retrieve the array of fence_infos pointed by info->sync_fence_info.

The first call should pass num_fences = 0, the kernel will then fill
info->num_fences. Userspace receives back the number of fences and
allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
info->sync_fence_info.

It then call the ioctl again passing num_fences received in info->num_fences.
The kernel checks if info->num_fences > 0 and if yes it fill
info->sync_fence_info with an array containing all fence_infos.

info->len now represents the length of the buffer sync_fence_info points
to. Also, info->sync_fence_info was converted to __u64 pointer.

An example userspace code would be:

	struct sync_file_info *info;
	int err, size, num_fences;

	info = malloc(sizeof(*info));

	memset(info, 0, sizeof(*info));

	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	num_fences = info->num_fences;

	if (num_fences) {
		memset(info, 0, sizeof(*info));
		size = sizeof(struct sync_fence_info) * num_fences;
		info->len = size;
		info->num_fences = num_fences;
		info->sync_fence_info = (uint64_t) calloc(num_fences,
							  sizeof(struct sync_fence_info));

		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	}

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/staging/android/sync.c      | 56 +++++++++++++++++++++++++++++--------
 drivers/staging/android/uapi/sync.h |  9 +++---
 2 files changed, 48 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..837cff5 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 					unsigned long arg)
 {
-	struct sync_file_info *info;
+	struct sync_file_info in, *info;
+	struct sync_fence_info *fence_info;
 	__u32 size;
 	__u32 len = 0;
 	int ret, i;
 
-	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+	if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
 		return -EFAULT;
 
-	if (size < sizeof(struct sync_file_info))
-		return -EINVAL;
+	if (in.status || strcmp(in.name, "\0"))
+		return -EFAULT;
 
-	if (size > 4096)
-		size = 4096;
+	if (in.num_fences && !in.sync_fence_info)
+		return -EFAULT;
 
-	info = kzalloc(size, GFP_KERNEL);
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
 	if (!info)
 		return -ENOMEM;
 
@@ -525,24 +526,55 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 	if (info->status >= 0)
 		info->status = !info->status;
 
-	info->num_fences = sync_file->num_fences;
+	/*
+	 * Passing num_fences = 0 means that userspace want to know how
+	 * many fences are in the sync_file to be able to allocate a buffer to
+	 * fit all sync_fence_infos and call the ioctl again with the buffer
+	 * assigned to info->sync_fence_info. The second call pass the
+	 * num_fences value received in the first call.
+	 */
+	if (!in.num_fences)
+		goto no_fences;
 
-	len = sizeof(struct sync_file_info);
+	size = sync_file->num_fences * sizeof(*fence_info);
+	if (in.len != size) {
+		ret = -EFAULT;
+		goto out;
+	}
+
+	fence_info = kzalloc(size, GFP_KERNEL);
+	if (!fence_info) {
+		ret = -ENOMEM;
+		goto out;
+	}
 
 	for (i = 0; i < sync_file->num_fences; ++i) {
 		struct fence *fence = sync_file->cbs[i].fence;
 
-		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+		ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
+					   size - len);
 
-		if (ret < 0)
+		if (ret < 0) {
+			kfree(fence_info);
 			goto out;
+		}
 
 		len += ret;
 	}
 
+	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
+		ret = -EFAULT;
+		kfree(fence_info);
+		goto out;
+	}
+
 	info->len = len;
+	info->sync_fence_info = (__u64) in.sync_fence_info;
+
+no_fences:
+	info->num_fences = sync_file->num_fences;
 
-	if (copy_to_user((void __user *)arg, info, len))
+	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
 		ret = -EFAULT;
 	else
 		ret = 0;
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index f0b41ce..9aad623 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -42,21 +42,20 @@ struct sync_fence_info {
 
 /**
  * struct sync_file_info - data returned from fence info ioctl
- * @len:	ioctl caller writes the size of the buffer its passing in.
- *		ioctl returns length of sync_file_info returned to
- *		userspace including pt_info.
  * @name:	name of fence
  * @status:	status of fence. 1: signaled 0:active <0:error
  * @num_fences	number of fences in the sync_file
+ * @len:	ioctl caller writes the size of the buffer its passing in.
+ *		ioctl returns length of all fence_infos summed.
  * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
  */
 struct sync_file_info {
-	__u32	len;
 	char	name[32];
 	__s32	status;
 	__u32	num_fences;
+	__u32	len;
 
-	__u8	sync_fence_info[0];
+	__u64	sync_fence_info;
 };
 
 #define SYNC_IOC_MAGIC		'>'
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer allocation. In the new approach the ioctl needs to be called
twice to retrieve the array of fence_infos pointed by info->sync_fence_info.

The first call should pass num_fences = 0, the kernel will then fill
info->num_fences. Userspace receives back the number of fences and
allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
info->sync_fence_info.

It then call the ioctl again passing num_fences received in info->num_fences.
The kernel checks if info->num_fences > 0 and if yes it fill
info->sync_fence_info with an array containing all fence_infos.

info->len now represents the length of the buffer sync_fence_info points
to. Also, info->sync_fence_info was converted to __u64 pointer.

An example userspace code would be:

	struct sync_file_info *info;
	int err, size, num_fences;

	info = malloc(sizeof(*info));

	memset(info, 0, sizeof(*info));

	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	num_fences = info->num_fences;

	if (num_fences) {
		memset(info, 0, sizeof(*info));
		size = sizeof(struct sync_fence_info) * num_fences;
		info->len = size;
		info->num_fences = num_fences;
		info->sync_fence_info = (uint64_t) calloc(num_fences,
							  sizeof(struct sync_fence_info));

		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
	}

v2: fix fence_info memory leak

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
 drivers/staging/android/uapi/sync.h |  9 +++----
 2 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..2379f23 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 					unsigned long arg)
 {
-	struct sync_file_info *info;
+	struct sync_file_info in, *info;
+	struct sync_fence_info *fence_info = NULL;
 	__u32 size;
 	__u32 len = 0;
 	int ret, i;
 
-	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+	if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
 		return -EFAULT;
 
-	if (size < sizeof(struct sync_file_info))
-		return -EINVAL;
+	if (in.status || strcmp(in.name, "\0"))
+		return -EFAULT;
 
-	if (size > 4096)
-		size = 4096;
+	if (in.num_fences && !in.sync_fence_info)
+		return -EFAULT;
 
-	info = kzalloc(size, GFP_KERNEL);
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
 	if (!info)
 		return -ENOMEM;
 
@@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 	if (info->status >= 0)
 		info->status = !info->status;
 
-	info->num_fences = sync_file->num_fences;
+	/*
+	 * Passing num_fences = 0 means that userspace want to know how
+	 * many fences are in the sync_file to be able to allocate a buffer to
+	 * fit all sync_fence_infos and call the ioctl again with the buffer
+	 * assigned to info->sync_fence_info. The second call pass the
+	 * num_fences value received in the first call.
+	 */
+	if (!in.num_fences)
+		goto no_fences;
+
+	size = sync_file->num_fences * sizeof(*fence_info);
+	if (in.len != size) {
+		ret = -EFAULT;
+		goto out;
+	}
 
-	len = sizeof(struct sync_file_info);
+	fence_info = kzalloc(size, GFP_KERNEL);
+	if (!fence_info) {
+		ret = -ENOMEM;
+		goto out;
+	}
 
 	for (i = 0; i < sync_file->num_fences; ++i) {
 		struct fence *fence = sync_file->cbs[i].fence;
 
-		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+		ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
+					   size - len);
 
 		if (ret < 0)
 			goto out;
@@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
 		len += ret;
 	}
 
+	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
+		ret = -EFAULT;
+		goto out;
+	}
+
 	info->len = len;
+	info->sync_fence_info = (__u64) in.sync_fence_info;
+
+no_fences:
+	info->num_fences = sync_file->num_fences;
 
-	if (copy_to_user((void __user *)arg, info, len))
+	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
 		ret = -EFAULT;
 	else
 		ret = 0;
 
 out:
+	kfree(fence_info);
 	kfree(info);
 
 	return ret;
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index f0b41ce..9aad623 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -42,21 +42,20 @@ struct sync_fence_info {
 
 /**
  * struct sync_file_info - data returned from fence info ioctl
- * @len:	ioctl caller writes the size of the buffer its passing in.
- *		ioctl returns length of sync_file_info returned to
- *		userspace including pt_info.
  * @name:	name of fence
  * @status:	status of fence. 1: signaled 0:active <0:error
  * @num_fences	number of fences in the sync_file
+ * @len:	ioctl caller writes the size of the buffer its passing in.
+ *		ioctl returns length of all fence_infos summed.
  * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
  */
 struct sync_file_info {
-	__u32	len;
 	char	name[32];
 	__s32	status;
 	__u32	num_fences;
+	__u32	len;
 
-	__u8	sync_fence_info[0];
+	__u64	sync_fence_info;
 };
 
 #define SYNC_IOC_MAGIC		'>'
-- 
2.5.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Emil Velikov]

Hi Gustavo,

On 26 February 2016 at 21:00, Gustavo Padovan <gustavo@padovan.org> wrote:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer allocation. In the new approach the ioctl needs to be called
> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
>
I might have misunderstood things but I no one says you "need" to call
it twice - you can just request a "random" amount of fences_info. Upon
return (if num_fences was non zero) it will report how many fence_info
were retrieved.

> The first call should pass num_fences = 0, the kernel will then fill
> info->num_fences. Userspace receives back the number of fences and
> allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> info->sync_fence_info.
>
> It then call the ioctl again passing num_fences received in info->num_fences.
"calls"

> The kernel checks if info->num_fences > 0 and if yes it fill
> info->sync_fence_info with an array containing all fence_infos.
>
The above sentence sounds a bit strange. I believe you meant to say
something like "Then the kernel fills the fence_infos array with data.
One should read back the actual number from info->num_fences." ?

> info->len now represents the length of the buffer sync_fence_info points
> to.
Now that I think about it, I'm wondering if there'll be a case where
len != info->num_fences * sizeof(struct sync_file_info). If that's not
possible one could just drop len and nicely simplify things.

> Also, info->sync_fence_info was converted to __u64 pointer.
>
... pointer to prevent 32bit compatibility issues.

> An example userspace code would be:
>
>         struct sync_file_info *info;
>         int err, size, num_fences;
>
>         info = malloc(sizeof(*info));
>
>         memset(info, 0, sizeof(*info));
>
>         err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>         num_fences = info->num_fences;
>
>         if (num_fences) {
>                 memset(info, 0, sizeof(*info));
>                 size = sizeof(struct sync_fence_info) * num_fences;
>                 info->len = size;
>                 info->num_fences = num_fences;
>                 info->sync_fence_info = (uint64_t) calloc(num_fences,
>                                                           sizeof(struct sync_fence_info));
>
>                 err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>         }
>
> v2: fix fence_info memory leak
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
>  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
>  drivers/staging/android/uapi/sync.h |  9 +++----
>  2 files changed, 45 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..2379f23 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>                                         unsigned long arg)
>  {
> -       struct sync_file_info *info;
> +       struct sync_file_info in, *info;
> +       struct sync_fence_info *fence_info = NULL;
>         __u32 size;
>         __u32 len = 0;
>         int ret, i;
>
> -       if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> +       if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
s/*info/in/

>                 return -EFAULT;
>
> -       if (size < sizeof(struct sync_file_info))
> -               return -EINVAL;
> +       if (in.status || strcmp(in.name, "\0"))
Afaict these two are outputs, so we should be checking them ?

> +               return -EFAULT;
>
As originally, input validation should return -EINVAL on error.


> -       if (size > 4096)
> -               size = 4096;
> +       if (in.num_fences && !in.sync_fence_info)
> +               return -EFAULT;
>
Ditto.

> -       info = kzalloc(size, GFP_KERNEL);
> +       info = kzalloc(sizeof(*info), GFP_KERNEL);
>         if (!info)
>                 return -ENOMEM;
>
> @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>         if (info->status >= 0)
>                 info->status = !info->status;
>
> -       info->num_fences = sync_file->num_fences;
> +       /*
> +        * Passing num_fences = 0 means that userspace want to know how
> +        * many fences are in the sync_file to be able to allocate a buffer to
> +        * fit all sync_fence_infos and call the ioctl again with the buffer
> +        * assigned to info->sync_fence_info. The second call pass the
> +        * num_fences value received in the first call.
> +        */
> +       if (!in.num_fences)
> +               goto no_fences;
> +
We should clamp in.num_fences to min2(in.num_fences,
sync_file->num_fences) and use it over sync_file->num_fences though
the rest of the function. Or just bail out when the two are not the
same.

Depends on what the planned semantics are. Fwiw I'm leaning towards the former.

> +       size = sync_file->num_fences * sizeof(*fence_info);
> +       if (in.len != size) {
> +               ret = -EFAULT;
EINVAL or just drop len from the struct.

> +               goto out;
> +       }
>
> -       len = sizeof(struct sync_file_info);
> +       fence_info = kzalloc(size, GFP_KERNEL);
> +       if (!fence_info) {
> +               ret = -ENOMEM;
> +               goto out;
> +       }
>
>         for (i = 0; i < sync_file->num_fences; ++i) {
>                 struct fence *fence = sync_file->cbs[i].fence;
>
> -               ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> +               ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
A few comments about sync_fill_fence_info()
 - Internal function so make the second argument of the correct type -
struct sync_fence_info *
 - Drop the third argument size, as that one is always sizeof(sync_fence_info).
 - Remove the size checking in the same function and make its return type void

Then one can simplify this loop even further :-)

> +                                          size - len);
>
>                 if (ret < 0)
>                         goto out;
> @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>                 len += ret;
>         }
>
> +       if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
> +               ret = -EFAULT;
> +               goto out;
> +       }
> +
>         info->len = len;
> +       info->sync_fence_info = (__u64) in.sync_fence_info;
Why the cast ?

> +
> +no_fences:
> +       info->num_fences = sync_file->num_fences;
>
> -       if (copy_to_user((void __user *)arg, info, len))
> +       if (copy_to_user((void __user *)arg, info, sizeof(*info)))
Don't know if we should be returning (copying) any other information
but info->num_fences in case of "no_fences". In case it's not clear -
I'm thinking about the data we already have in in info->name and
info->status.

Regards,
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

Hi Emil,

2016-02-27 Emil Velikov <emil.l.velikov@gmail.com>:

> Hi Gustavo,
> 
> On 26 February 2016 at 21:00, Gustavo Padovan <gustavo@padovan.org> wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> > optimize buffer allocation. In the new approach the ioctl needs to be called
> > twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
> >
> I might have misunderstood things but I no one says you "need" to call
> it twice - you can just request a "random" amount of fences_info. Upon
> return (if num_fences was non zero) it will report how many fence_info
> were retrieved.

Right, I don't see any problem doing it in one request, I just didn't 
think about that in the new proposal. I'll update the code and commit
message accordinly.

> 
> > The first call should pass num_fences = 0, the kernel will then fill
> > info->num_fences. Userspace receives back the number of fences and
> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> > info->sync_fence_info.
> >
> > It then call the ioctl again passing num_fences received in info->num_fences.
> "calls"
> 
> > The kernel checks if info->num_fences > 0 and if yes it fill
> > info->sync_fence_info with an array containing all fence_infos.
> >
> The above sentence sounds a bit strange. I believe you meant to say
> something like "Then the kernel fills the fence_infos array with data.
> One should read back the actual number from info->num_fences." ?
> 
> > info->len now represents the length of the buffer sync_fence_info points
> > to.
> Now that I think about it, I'm wondering if there'll be a case where
> len != info->num_fences * sizeof(struct sync_file_info). If that's not
> possible one could just drop len and nicely simplify things.
> 
> > Also, info->sync_fence_info was converted to __u64 pointer.
> >
> ... pointer to prevent 32bit compatibility issues.
> 
> > An example userspace code would be:
> >
> >         struct sync_file_info *info;
> >         int err, size, num_fences;
> >
> >         info = malloc(sizeof(*info));
> >
> >         memset(info, 0, sizeof(*info));
> >
> >         err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> >         num_fences = info->num_fences;
> >
> >         if (num_fences) {
> >                 memset(info, 0, sizeof(*info));
> >                 size = sizeof(struct sync_fence_info) * num_fences;
> >                 info->len = size;
> >                 info->num_fences = num_fences;
> >                 info->sync_fence_info = (uint64_t) calloc(num_fences,
> >                                                           sizeof(struct sync_fence_info));
> >
> >                 err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> >         }
> >
> > v2: fix fence_info memory leak
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > ---
> >  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
> >  drivers/staging/android/uapi/sync.h |  9 +++----
> >  2 files changed, 45 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> > index dc5f382..2379f23 100644
> > --- a/drivers/staging/android/sync.c
> > +++ b/drivers/staging/android/sync.c
> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
> >  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >                                         unsigned long arg)
> >  {
> > -       struct sync_file_info *info;
> > +       struct sync_file_info in, *info;
> > +       struct sync_fence_info *fence_info = NULL;
> >         __u32 size;
> >         __u32 len = 0;
> >         int ret, i;
> >
> > -       if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> > +       if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
> s/*info/in/
> 
> >                 return -EFAULT;
> >
> > -       if (size < sizeof(struct sync_file_info))
> > -               return -EINVAL;
> > +       if (in.status || strcmp(in.name, "\0"))
> Afaict these two are outputs, so we should be checking them ?

Hmm. Maybe not.

> 
> > +               return -EFAULT;
> >
> As originally, input validation should return -EINVAL on error.
> 
> 
> > -       if (size > 4096)
> > -               size = 4096;
> > +       if (in.num_fences && !in.sync_fence_info)
> > +               return -EFAULT;
> >
> Ditto.
> 
> > -       info = kzalloc(size, GFP_KERNEL);
> > +       info = kzalloc(sizeof(*info), GFP_KERNEL);
> >         if (!info)
> >                 return -ENOMEM;
> >
> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >         if (info->status >= 0)
> >                 info->status = !info->status;
> >
> > -       info->num_fences = sync_file->num_fences;
> > +       /*
> > +        * Passing num_fences = 0 means that userspace want to know how
> > +        * many fences are in the sync_file to be able to allocate a buffer to
> > +        * fit all sync_fence_infos and call the ioctl again with the buffer
> > +        * assigned to info->sync_fence_info. The second call pass the
> > +        * num_fences value received in the first call.
> > +        */
> > +       if (!in.num_fences)
> > +               goto no_fences;
> > +
> We should clamp in.num_fences to min2(in.num_fences,
> sync_file->num_fences) and use it over sync_file->num_fences though
> the rest of the function. Or just bail out when the two are not the
> same.
> 
> Depends on what the planned semantics are. Fwiw I'm leaning towards the former.

If num_fences received is smaller than the actual num_fences I think we
should fails, otherwise we should just fill the buffer with all
fence_infos...

> 
> > +       size = sync_file->num_fences * sizeof(*fence_info);
> > +       if (in.len != size) {
> > +               ret = -EFAULT;
> EINVAL or just drop len from the struct.

...so this check now would be in.len < size.

> 
> > +               goto out;
> > +       }
> >
> > -       len = sizeof(struct sync_file_info);
> > +       fence_info = kzalloc(size, GFP_KERNEL);
> > +       if (!fence_info) {
> > +               ret = -ENOMEM;
> > +               goto out;
> > +       }
> >
> >         for (i = 0; i < sync_file->num_fences; ++i) {
> >                 struct fence *fence = sync_file->cbs[i].fence;
> >
> > -               ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> > +               ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
> A few comments about sync_fill_fence_info()
>  - Internal function so make the second argument of the correct type -
> struct sync_fence_info *
>  - Drop the third argument size, as that one is always sizeof(sync_fence_info).
>  - Remove the size checking in the same function and make its return type void
> 
> Then one can simplify this loop even further :-)

Sounds good to me.

> 
> > +                                          size - len);
> >
> >                 if (ret < 0)
> >                         goto out;
> > @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >                 len += ret;
> >         }
> >
> > +       if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
> > +               ret = -EFAULT;
> > +               goto out;
> > +       }
> > +
> >         info->len = len;
> > +       info->sync_fence_info = (__u64) in.sync_fence_info;
> Why the cast ?
> 
> > +
> > +no_fences:
> > +       info->num_fences = sync_file->num_fences;
> >
> > -       if (copy_to_user((void __user *)arg, info, len))
> > +       if (copy_to_user((void __user *)arg, info, sizeof(*info)))
> Don't know if we should be returning (copying) any other information
> but info->num_fences in case of "no_fences". In case it's not clear -
> I'm thinking about the data we already have in in info->name and
> info->status.

Userspace might want to know all info about the sync_file but
sync_fence_info.

	Gustavo

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Emil Velikov]

Hi Gustavo,

On 27 February 2016 at 15:25, Gustavo Padovan
<gustavo.padovan@collabora.co.uk> wrote:
> Hi Emil,
>
> 2016-02-27 Emil Velikov <emil.l.velikov@gmail.com>:
>
>> Hi Gustavo,
>>
>> On 26 February 2016 at 21:00, Gustavo Padovan <gustavo@padovan.org> wrote:
>> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>> >
>> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
>> > optimize buffer allocation. In the new approach the ioctl needs to be called
>> > twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
>> >
>> I might have misunderstood things but I no one says you "need" to call
>> it twice - you can just request a "random" amount of fences_info. Upon
>> return (if num_fences was non zero) it will report how many fence_info
>> were retrieved.
>
> Right, I don't see any problem doing it in one request, I just didn't
> think about that in the new proposal. I'll update the code and commit
> message accordinly.
>
>>
>> > The first call should pass num_fences = 0, the kernel will then fill
>> > info->num_fences. Userspace receives back the number of fences and
>> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
>> > info->sync_fence_info.
>> >
>> > It then call the ioctl again passing num_fences received in info->num_fences.
>> "calls"
>>
>> > The kernel checks if info->num_fences > 0 and if yes it fill
>> > info->sync_fence_info with an array containing all fence_infos.
>> >
>> The above sentence sounds a bit strange. I believe you meant to say
>> something like "Then the kernel fills the fence_infos array with data.
>> One should read back the actual number from info->num_fences." ?
>>
>> > info->len now represents the length of the buffer sync_fence_info points
>> > to.
>> Now that I think about it, I'm wondering if there'll be a case where
>> len != info->num_fences * sizeof(struct sync_file_info). If that's not
>> possible one could just drop len and nicely simplify things.
>>
>> > Also, info->sync_fence_info was converted to __u64 pointer.
>> >
>> ... pointer to prevent 32bit compatibility issues.
>>
>> > An example userspace code would be:
>> >
>> >         struct sync_file_info *info;
>> >         int err, size, num_fences;
>> >
>> >         info = malloc(sizeof(*info));
>> >
>> >         memset(info, 0, sizeof(*info));
>> >
>> >         err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>> >         num_fences = info->num_fences;
>> >
>> >         if (num_fences) {
>> >                 memset(info, 0, sizeof(*info));
>> >                 size = sizeof(struct sync_fence_info) * num_fences;
>> >                 info->len = size;
>> >                 info->num_fences = num_fences;
>> >                 info->sync_fence_info = (uint64_t) calloc(num_fences,
>> >                                                           sizeof(struct sync_fence_info));
>> >
>> >                 err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>> >         }
>> >
>> > v2: fix fence_info memory leak
>> >
>> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>> > ---
>> >  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
>> >  drivers/staging/android/uapi/sync.h |  9 +++----
>> >  2 files changed, 45 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
>> > index dc5f382..2379f23 100644
>> > --- a/drivers/staging/android/sync.c
>> > +++ b/drivers/staging/android/sync.c
>> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
>> >  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>> >                                         unsigned long arg)
>> >  {
>> > -       struct sync_file_info *info;
>> > +       struct sync_file_info in, *info;
>> > +       struct sync_fence_info *fence_info = NULL;
>> >         __u32 size;
>> >         __u32 len = 0;
>> >         int ret, i;
>> >
>> > -       if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
>> > +       if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
>> s/*info/in/
>>
>> >                 return -EFAULT;
>> >
>> > -       if (size < sizeof(struct sync_file_info))
>> > -               return -EINVAL;
>> > +       if (in.status || strcmp(in.name, "\0"))
>> Afaict these two are outputs, so we should be checking them ?
>
> Hmm. Maybe not.
>
>>
>> > +               return -EFAULT;
>> >
>> As originally, input validation should return -EINVAL on error.
>>
>>
>> > -       if (size > 4096)
>> > -               size = 4096;
>> > +       if (in.num_fences && !in.sync_fence_info)
>> > +               return -EFAULT;
>> >
>> Ditto.
>>
>> > -       info = kzalloc(size, GFP_KERNEL);
>> > +       info = kzalloc(sizeof(*info), GFP_KERNEL);
>> >         if (!info)
>> >                 return -ENOMEM;
>> >
>> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>> >         if (info->status >= 0)
>> >                 info->status = !info->status;
>> >
>> > -       info->num_fences = sync_file->num_fences;
>> > +       /*
>> > +        * Passing num_fences = 0 means that userspace want to know how
>> > +        * many fences are in the sync_file to be able to allocate a buffer to
>> > +        * fit all sync_fence_infos and call the ioctl again with the buffer
>> > +        * assigned to info->sync_fence_info. The second call pass the
>> > +        * num_fences value received in the first call.
>> > +        */
>> > +       if (!in.num_fences)
>> > +               goto no_fences;
>> > +
>> We should clamp in.num_fences to min2(in.num_fences,
>> sync_file->num_fences) and use it over sync_file->num_fences though
>> the rest of the function. Or just bail out when the two are not the
>> same.
>>
>> Depends on what the planned semantics are. Fwiw I'm leaning towards the former.
>
> If num_fences received is smaller than the actual num_fences I think we
> should fails, otherwise we should just fill the buffer with all
> fence_infos...
>
Fair enough. Just make sure that this is clearly explained to the use
- manpages, other ?

>>
>> > +       size = sync_file->num_fences * sizeof(*fence_info);
>> > +       if (in.len != size) {
>> > +               ret = -EFAULT;
>> EINVAL or just drop len from the struct.
>
> ...so this check now would be in.len < size.
>
>>
>> > +               goto out;
>> > +       }
>> >
>> > -       len = sizeof(struct sync_file_info);
>> > +       fence_info = kzalloc(size, GFP_KERNEL);
>> > +       if (!fence_info) {
>> > +               ret = -ENOMEM;
>> > +               goto out;
>> > +       }
>> >
>> >         for (i = 0; i < sync_file->num_fences; ++i) {
>> >                 struct fence *fence = sync_file->cbs[i].fence;
>> >
>> > -               ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
>> > +               ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
>> A few comments about sync_fill_fence_info()
>>  - Internal function so make the second argument of the correct type -
>> struct sync_fence_info *
>>  - Drop the third argument size, as that one is always sizeof(sync_fence_info).
>>  - Remove the size checking in the same function and make its return type void
>>
>> Then one can simplify this loop even further :-)
>
> Sounds good to me.
>
>>
>> > +                                          size - len);
>> >
>> >                 if (ret < 0)
>> >                         goto out;
>> > @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>> >                 len += ret;
>> >         }
>> >
>> > +       if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
>> > +               ret = -EFAULT;
>> > +               goto out;
>> > +       }
>> > +
>> >         info->len = len;
>> > +       info->sync_fence_info = (__u64) in.sync_fence_info;
>> Why the cast ?
>>
>> > +
>> > +no_fences:
>> > +       info->num_fences = sync_file->num_fences;
>> >
>> > -       if (copy_to_user((void __user *)arg, info, len))
>> > +       if (copy_to_user((void __user *)arg, info, sizeof(*info)))
>> Don't know if we should be returning (copying) any other information
>> but info->num_fences in case of "no_fences". In case it's not clear -
>> I'm thinking about the data we already have in in info->name and
>> info->status.
>
> Userspace might want to know all info about the sync_file but
> sync_fence_info.
>
IMHO, that does sound like a rather strange use of the API. Whichever
route one goes for, it would be nice to have the behaviour clearly
documented. Otherwise things will end up quite confusing.
Documentation can be done in separate patch/series.

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Maarten Lankhorst]

Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer allocation. In the new approach the ioctl needs to be called
> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
>
> The first call should pass num_fences = 0, the kernel will then fill
> info->num_fences. Userspace receives back the number of fences and
> allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> info->sync_fence_info.
>
> It then call the ioctl again passing num_fences received in info->num_fences.
> The kernel checks if info->num_fences > 0 and if yes it fill
> info->sync_fence_info with an array containing all fence_infos.
>
> info->len now represents the length of the buffer sync_fence_info points
> to. Also, info->sync_fence_info was converted to __u64 pointer.
>
> An example userspace code would be:
>
> 	struct sync_file_info *info;
> 	int err, size, num_fences;
>
> 	info = malloc(sizeof(*info));
>
> 	memset(info, 0, sizeof(*info));
>
> 	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> 	num_fences = info->num_fences;
>
> 	if (num_fences) {
> 		memset(info, 0, sizeof(*info));
Would this memset still be needed if we didn't check for nulls in info->status and info->name ?

Seems to me that it could be skipped in that case.
> 		size = sizeof(struct sync_fence_info) * num_fences;
> 		info->len = size;
> 		info->num_fences = num_fences;
> 		info->sync_fence_info = (uint64_t) calloc(num_fences,
> 							  sizeof(struct sync_fence_info));
>
> 		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> 	}
>
> v2: fix fence_info memory leak
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
>  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
>  drivers/staging/android/uapi/sync.h |  9 +++----
>  2 files changed, 45 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..2379f23 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>  					unsigned long arg)
>  {
> -	struct sync_file_info *info;
> +	struct sync_file_info in, *info;
> +	struct sync_fence_info *fence_info = NULL;
>  	__u32 size;
>  	__u32 len = 0;
= 0 unneeded.
>  	int ret, i;
>  
> -	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> +	if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
>  		return -EFAULT;
>  
> -	if (size < sizeof(struct sync_file_info))
> -		return -EINVAL;
> +	if (in.status || strcmp(in.name, "\0"))
> +		return -EFAULT;
These members always get written by the fence ioctl, I'm not sure it adds value to have them explicitly zero'd out by userspace.
> -	if (size > 4096)
> -		size = 4096;
> +	if (in.num_fences && !in.sync_fence_info)
> +		return -EFAULT;
This check is unneeded, it will happen in the copy_to_user call anyway.
> -	info = kzalloc(size, GFP_KERNEL);
> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
>  	if (!info)
>  		return -ENOMEM;
>  
> @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>  	if (info->status >= 0)
>  		info->status = !info->status;
>  
> -	info->num_fences = sync_file->num_fences;
> +	/*
> +	 * Passing num_fences = 0 means that userspace want to know how
> +	 * many fences are in the sync_file to be able to allocate a buffer to
> +	 * fit all sync_fence_infos and call the ioctl again with the buffer
> +	 * assigned to info->sync_fence_info. The second call pass the
> +	 * num_fences value received in the first call.
> +	 */
> +	if (!in.num_fences)
> +		goto no_fences;
> +
> +	size = sync_file->num_fences * sizeof(*fence_info);
> +	if (in.len != size) {
> +		ret = -EFAULT;
> +		goto out;
> +	}
Maybe check for in.len < size, and set set to size?


> -	len = sizeof(struct sync_file_info);
> +	fence_info = kzalloc(size, GFP_KERNEL);
> +	if (!fence_info) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
>  
>  	for (i = 0; i < sync_file->num_fences; ++i) {
>  		struct fence *fence = sync_file->cbs[i].fence;
>  
> -		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> +		ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
> +					   size - len);
>  
>  		if (ret < 0)
>  			goto out;
> @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>  		len += ret;
>  	}
>  
> +	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
> +		ret = -EFAULT;
> +		goto out;
> +	}
> +
>  	info->len = len;
> +	info->sync_fence_info = (__u64) in.sync_fence_info;
> +
> +no_fences:
> +	info->num_fences = sync_file->num_fences;
>  
> -	if (copy_to_user((void __user *)arg, info, len))
> +	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
>  		ret = -EFAULT;
>  	else
>  		ret = 0;
>  
>  out:
> +	kfree(fence_info);
>  	kfree(info);
>  
>  	return ret;
> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
> index f0b41ce..9aad623 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -42,21 +42,20 @@ struct sync_fence_info {
>  
>  /**
>   * struct sync_file_info - data returned from fence info ioctl
> - * @len:	ioctl caller writes the size of the buffer its passing in.
> - *		ioctl returns length of sync_file_info returned to
> - *		userspace including pt_info.
>   * @name:	name of fence
>   * @status:	status of fence. 1: signaled 0:active <0:error
>   * @num_fences	number of fences in the sync_file
> + * @len:	ioctl caller writes the size of the buffer its passing in.
> + *		ioctl returns length of all fence_infos summed.
>   * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
>   */
>  struct sync_file_info {
> -	__u32	len;
>  	char	name[32];
>  	__s32	status;
>  	__u32	num_fences;
> +	__u32	len;
>  
> -	__u8	sync_fence_info[0];
> +	__u64	sync_fence_info;
>  };
>  
>  #define SYNC_IOC_MAGIC		'>'
Not sure if len adds anything here, userspace knows to allocate num_fences * sizeof(struct sync_fence_info);

It could probably be removed since num_fences would do the same.

~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

Hi Maarten,

2016-02-29 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:

> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> > optimize buffer allocation. In the new approach the ioctl needs to be called
> > twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
> >
> > The first call should pass num_fences = 0, the kernel will then fill
> > info->num_fences. Userspace receives back the number of fences and
> > allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> > info->sync_fence_info.
> >
> > It then call the ioctl again passing num_fences received in info->num_fences.
> > The kernel checks if info->num_fences > 0 and if yes it fill
> > info->sync_fence_info with an array containing all fence_infos.
> >
> > info->len now represents the length of the buffer sync_fence_info points
> > to. Also, info->sync_fence_info was converted to __u64 pointer.
> >
> > An example userspace code would be:
> >
> > 	struct sync_file_info *info;
> > 	int err, size, num_fences;
> >
> > 	info = malloc(sizeof(*info));
> >
> > 	memset(info, 0, sizeof(*info));
> >
> > 	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> > 	num_fences = info->num_fences;
> >
> > 	if (num_fences) {
> > 		memset(info, 0, sizeof(*info));
> Would this memset still be needed if we didn't check for nulls in info->status and info->name ?
> 
> Seems to me that it could be skipped in that case.

Yes, I agree.

> > 		size = sizeof(struct sync_fence_info) * num_fences;
> > 		info->len = size;
> > 		info->num_fences = num_fences;
> > 		info->sync_fence_info = (uint64_t) calloc(num_fences,
> > 							  sizeof(struct sync_fence_info));
> >
> > 		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> > 	}
> >
> > v2: fix fence_info memory leak
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > ---
> >  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
> >  drivers/staging/android/uapi/sync.h |  9 +++----
> >  2 files changed, 45 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> > index dc5f382..2379f23 100644
> > --- a/drivers/staging/android/sync.c
> > +++ b/drivers/staging/android/sync.c
> > @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
> >  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >  					unsigned long arg)
> >  {
> > -	struct sync_file_info *info;
> > +	struct sync_file_info in, *info;
> > +	struct sync_fence_info *fence_info = NULL;
> >  	__u32 size;
> >  	__u32 len = 0;
> = 0 unneeded.
> >  	int ret, i;
> >  
> > -	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> > +	if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
> >  		return -EFAULT;
> >  
> > -	if (size < sizeof(struct sync_file_info))
> > -		return -EINVAL;
> > +	if (in.status || strcmp(in.name, "\0"))
> > +		return -EFAULT;
> These members always get written by the fence ioctl, I'm not sure it adds value to have them explicitly zero'd out by userspace.
> > -	if (size > 4096)
> > -		size = 4096;
> > +	if (in.num_fences && !in.sync_fence_info)
> > +		return -EFAULT;
> This check is unneeded, it will happen in the copy_to_user call anyway.
> > -	info = kzalloc(size, GFP_KERNEL);
> > +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> >  	if (!info)
> >  		return -ENOMEM;
> >  
> > @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >  	if (info->status >= 0)
> >  		info->status = !info->status;
> >  
> > -	info->num_fences = sync_file->num_fences;
> > +	/*
> > +	 * Passing num_fences = 0 means that userspace want to know how
> > +	 * many fences are in the sync_file to be able to allocate a buffer to
> > +	 * fit all sync_fence_infos and call the ioctl again with the buffer
> > +	 * assigned to info->sync_fence_info. The second call pass the
> > +	 * num_fences value received in the first call.
> > +	 */
> > +	if (!in.num_fences)
> > +		goto no_fences;
> > +
> > +	size = sync_file->num_fences * sizeof(*fence_info);
> > +	if (in.len != size) {
> > +		ret = -EFAULT;
> > +		goto out;
> > +	}
> Maybe check for in.len < size, and set set to size?
> 
> 
> > -	len = sizeof(struct sync_file_info);
> > +	fence_info = kzalloc(size, GFP_KERNEL);
> > +	if (!fence_info) {
> > +		ret = -ENOMEM;
> > +		goto out;
> > +	}
> >  
> >  	for (i = 0; i < sync_file->num_fences; ++i) {
> >  		struct fence *fence = sync_file->cbs[i].fence;
> >  
> > -		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> > +		ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
> > +					   size - len);
> >  
> >  		if (ret < 0)
> >  			goto out;
> > @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >  		len += ret;
> >  	}
> >  
> > +	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
> > +		ret = -EFAULT;
> > +		goto out;
> > +	}
> > +
> >  	info->len = len;
> > +	info->sync_fence_info = (__u64) in.sync_fence_info;
> > +
> > +no_fences:
> > +	info->num_fences = sync_file->num_fences;
> >  
> > -	if (copy_to_user((void __user *)arg, info, len))
> > +	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
> >  		ret = -EFAULT;
> >  	else
> >  		ret = 0;
> >  
> >  out:
> > +	kfree(fence_info);
> >  	kfree(info);
> >  
> >  	return ret;
> > diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
> > index f0b41ce..9aad623 100644
> > --- a/drivers/staging/android/uapi/sync.h
> > +++ b/drivers/staging/android/uapi/sync.h
> > @@ -42,21 +42,20 @@ struct sync_fence_info {
> >  
> >  /**
> >   * struct sync_file_info - data returned from fence info ioctl
> > - * @len:	ioctl caller writes the size of the buffer its passing in.
> > - *		ioctl returns length of sync_file_info returned to
> > - *		userspace including pt_info.
> >   * @name:	name of fence
> >   * @status:	status of fence. 1: signaled 0:active <0:error
> >   * @num_fences	number of fences in the sync_file
> > + * @len:	ioctl caller writes the size of the buffer its passing in.
> > + *		ioctl returns length of all fence_infos summed.
> >   * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
> >   */
> >  struct sync_file_info {
> > -	__u32	len;
> >  	char	name[32];
> >  	__s32	status;
> >  	__u32	num_fences;
> > +	__u32	len;
> >  
> > -	__u8	sync_fence_info[0];
> > +	__u64	sync_fence_info;
> >  };
> >  
> >  #define SYNC_IOC_MAGIC		'>'
> Not sure if len adds anything here, userspace knows to allocate num_fences * sizeof(struct sync_fence_info);

I think of len being useful if we decide to extend struct sync_fence_info in
the future, so we may use len to help discover the size of each
sync_fence_info. What do you think?

	Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Maarten Lankhorst]

Op 29-02-16 om 23:08 schreef Gustavo Padovan:
> Hi Maarten,
>
> 2016-02-29 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
>
>> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
>>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>>
>>> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
>>> optimize buffer allocation. In the new approach the ioctl needs to be called
>>> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
>>>
>>> The first call should pass num_fences = 0, the kernel will then fill
>>> info->num_fences. Userspace receives back the number of fences and
>>> allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
>>> info->sync_fence_info.
>>>
>>> It then call the ioctl again passing num_fences received in info->num_fences.
>>> The kernel checks if info->num_fences > 0 and if yes it fill
>>> info->sync_fence_info with an array containing all fence_infos.
>>>
>>> info->len now represents the length of the buffer sync_fence_info points
>>> to. Also, info->sync_fence_info was converted to __u64 pointer.
>>>
>>> An example userspace code would be:
>>>
>>> 	struct sync_file_info *info;
>>> 	int err, size, num_fences;
>>>
>>> 	info = malloc(sizeof(*info));
>>>
>>> 	memset(info, 0, sizeof(*info));
>>>
>>> 	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>>> 	num_fences = info->num_fences;
>>>
>>> 	if (num_fences) {
>>> 		memset(info, 0, sizeof(*info));
>> Would this memset still be needed if we didn't check for nulls in info->status and info->name ?
>>
>> Seems to me that it could be skipped in that case.
> Yes, I agree.
>
>>> 		size = sizeof(struct sync_fence_info) * num_fences;
>>> 		info->len = size;
>>> 		info->num_fences = num_fences;
>>> 		info->sync_fence_info = (uint64_t) calloc(num_fences,
>>> 							  sizeof(struct sync_fence_info));
>>>
>>> 		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
>>> 	}
>>>
>>> v2: fix fence_info memory leak
>>>
>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>> ---
>>>  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
>>>  drivers/staging/android/uapi/sync.h |  9 +++----
>>>  2 files changed, 45 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
>>> index dc5f382..2379f23 100644
>>> --- a/drivers/staging/android/sync.c
>>> +++ b/drivers/staging/android/sync.c
>>> @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
>>>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>>>  					unsigned long arg)
>>>  {
>>> -	struct sync_file_info *info;
>>> +	struct sync_file_info in, *info;
>>> +	struct sync_fence_info *fence_info = NULL;
>>>  	__u32 size;
>>>  	__u32 len = 0;
>> = 0 unneeded.
>>>  	int ret, i;
>>>  
>>> -	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
>>> +	if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
>>>  		return -EFAULT;
>>>  
>>> -	if (size < sizeof(struct sync_file_info))
>>> -		return -EINVAL;
>>> +	if (in.status || strcmp(in.name, "\0"))
>>> +		return -EFAULT;
>> These members always get written by the fence ioctl, I'm not sure it adds value to have them explicitly zero'd out by userspace.
>>> -	if (size > 4096)
>>> -		size = 4096;
>>> +	if (in.num_fences && !in.sync_fence_info)
>>> +		return -EFAULT;
>> This check is unneeded, it will happen in the copy_to_user call anyway.
>>> -	info = kzalloc(size, GFP_KERNEL);
>>> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>  	if (!info)
>>>  		return -ENOMEM;
>>>  
>>> @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>>>  	if (info->status >= 0)
>>>  		info->status = !info->status;
>>>  
>>> -	info->num_fences = sync_file->num_fences;
>>> +	/*
>>> +	 * Passing num_fences = 0 means that userspace want to know how
>>> +	 * many fences are in the sync_file to be able to allocate a buffer to
>>> +	 * fit all sync_fence_infos and call the ioctl again with the buffer
>>> +	 * assigned to info->sync_fence_info. The second call pass the
>>> +	 * num_fences value received in the first call.
>>> +	 */
>>> +	if (!in.num_fences)
>>> +		goto no_fences;
>>> +
>>> +	size = sync_file->num_fences * sizeof(*fence_info);
>>> +	if (in.len != size) {
>>> +		ret = -EFAULT;
>>> +		goto out;
>>> +	}
>> Maybe check for in.len < size, and set set to size?
>>
>>
>>> -	len = sizeof(struct sync_file_info);
>>> +	fence_info = kzalloc(size, GFP_KERNEL);
>>> +	if (!fence_info) {
>>> +		ret = -ENOMEM;
>>> +		goto out;
>>> +	}
>>>  
>>>  	for (i = 0; i < sync_file->num_fences; ++i) {
>>>  		struct fence *fence = sync_file->cbs[i].fence;
>>>  
>>> -		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
>>> +		ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
>>> +					   size - len);
>>>  
>>>  		if (ret < 0)
>>>  			goto out;
>>> @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>>>  		len += ret;
>>>  	}
>>>  
>>> +	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
>>> +		ret = -EFAULT;
>>> +		goto out;
>>> +	}
>>> +
>>>  	info->len = len;
>>> +	info->sync_fence_info = (__u64) in.sync_fence_info;
>>> +
>>> +no_fences:
>>> +	info->num_fences = sync_file->num_fences;
>>>  
>>> -	if (copy_to_user((void __user *)arg, info, len))
>>> +	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
>>>  		ret = -EFAULT;
>>>  	else
>>>  		ret = 0;
>>>  
>>>  out:
>>> +	kfree(fence_info);
>>>  	kfree(info);
>>>  
>>>  	return ret;
>>> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
>>> index f0b41ce..9aad623 100644
>>> --- a/drivers/staging/android/uapi/sync.h
>>> +++ b/drivers/staging/android/uapi/sync.h
>>> @@ -42,21 +42,20 @@ struct sync_fence_info {
>>>  
>>>  /**
>>>   * struct sync_file_info - data returned from fence info ioctl
>>> - * @len:	ioctl caller writes the size of the buffer its passing in.
>>> - *		ioctl returns length of sync_file_info returned to
>>> - *		userspace including pt_info.
>>>   * @name:	name of fence
>>>   * @status:	status of fence. 1: signaled 0:active <0:error
>>>   * @num_fences	number of fences in the sync_file
>>> + * @len:	ioctl caller writes the size of the buffer its passing in.
>>> + *		ioctl returns length of all fence_infos summed.
>>>   * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
>>>   */
>>>  struct sync_file_info {
>>> -	__u32	len;
>>>  	char	name[32];
>>>  	__s32	status;
>>>  	__u32	num_fences;
>>> +	__u32	len;
>>>  
>>> -	__u8	sync_fence_info[0];
>>> +	__u64	sync_fence_info;
>>>  };
>>>  
>>>  #define SYNC_IOC_MAGIC		'>'
>> Not sure if len adds anything here, userspace knows to allocate num_fences * sizeof(struct sync_fence_info);
> I think of len being useful if we decide to extend struct sync_fence_info in
> the future, so we may use len to help discover the size of each
> sync_fence_info. What do you think?
>
I don't think you could extend it arbitrarily, you could make userspace pass a flag to indicate the struct is extended, so kernel space can choose
whether to use the bigger size struct or not.

something like sync_file_info.flags = FENCE_INFO_V2; -- kernel can reject with -EINVAL if unsupported, or fill in a v2 struct.

~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

Hi Maarten,

2016-03-01 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:

> Op 29-02-16 om 23:08 schreef Gustavo Padovan:
> > Hi Maarten,
> >
> > 2016-02-29 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
> >
> >> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> >>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >>>
> >>> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> >>> optimize buffer allocation. In the new approach the ioctl needs to be called
> >>> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
> >>>
> >>> The first call should pass num_fences = 0, the kernel will then fill
> >>> info->num_fences. Userspace receives back the number of fences and
> >>> allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
> >>> info->sync_fence_info.
> >>>
> >>> It then call the ioctl again passing num_fences received in info->num_fences.
> >>> The kernel checks if info->num_fences > 0 and if yes it fill
> >>> info->sync_fence_info with an array containing all fence_infos.
> >>>
> >>> info->len now represents the length of the buffer sync_fence_info points
> >>> to. Also, info->sync_fence_info was converted to __u64 pointer.
> >>>
> >>> An example userspace code would be:
> >>>
> >>> 	struct sync_file_info *info;
> >>> 	int err, size, num_fences;
> >>>
> >>> 	info = malloc(sizeof(*info));
> >>>
> >>> 	memset(info, 0, sizeof(*info));
> >>>
> >>> 	err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> >>> 	num_fences = info->num_fences;
> >>>
> >>> 	if (num_fences) {
> >>> 		memset(info, 0, sizeof(*info));
> >> Would this memset still be needed if we didn't check for nulls in info->status and info->name ?
> >>
> >> Seems to me that it could be skipped in that case.
> > Yes, I agree.
> >
> >>> 		size = sizeof(struct sync_fence_info) * num_fences;
> >>> 		info->len = size;
> >>> 		info->num_fences = num_fences;
> >>> 		info->sync_fence_info = (uint64_t) calloc(num_fences,
> >>> 							  sizeof(struct sync_fence_info));
> >>>
> >>> 		err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
> >>> 	}
> >>>
> >>> v2: fix fence_info memory leak
> >>>
> >>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >>> ---
> >>>  drivers/staging/android/sync.c      | 52 +++++++++++++++++++++++++++++--------
> >>>  drivers/staging/android/uapi/sync.h |  9 +++----
> >>>  2 files changed, 45 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> >>> index dc5f382..2379f23 100644
> >>> --- a/drivers/staging/android/sync.c
> >>> +++ b/drivers/staging/android/sync.c
> >>> @@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
> >>>  static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >>>  					unsigned long arg)
> >>>  {
> >>> -	struct sync_file_info *info;
> >>> +	struct sync_file_info in, *info;
> >>> +	struct sync_fence_info *fence_info = NULL;
> >>>  	__u32 size;
> >>>  	__u32 len = 0;
> >> = 0 unneeded.
> >>>  	int ret, i;
> >>>  
> >>> -	if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
> >>> +	if (copy_from_user(&in, (void __user *)arg, sizeof(*info)))
> >>>  		return -EFAULT;
> >>>  
> >>> -	if (size < sizeof(struct sync_file_info))
> >>> -		return -EINVAL;
> >>> +	if (in.status || strcmp(in.name, "\0"))
> >>> +		return -EFAULT;
> >> These members always get written by the fence ioctl, I'm not sure it adds value to have them explicitly zero'd out by userspace.
> >>> -	if (size > 4096)
> >>> -		size = 4096;
> >>> +	if (in.num_fences && !in.sync_fence_info)
> >>> +		return -EFAULT;
> >> This check is unneeded, it will happen in the copy_to_user call anyway.
> >>> -	info = kzalloc(size, GFP_KERNEL);
> >>> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>>  	if (!info)
> >>>  		return -ENOMEM;
> >>>  
> >>> @@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >>>  	if (info->status >= 0)
> >>>  		info->status = !info->status;
> >>>  
> >>> -	info->num_fences = sync_file->num_fences;
> >>> +	/*
> >>> +	 * Passing num_fences = 0 means that userspace want to know how
> >>> +	 * many fences are in the sync_file to be able to allocate a buffer to
> >>> +	 * fit all sync_fence_infos and call the ioctl again with the buffer
> >>> +	 * assigned to info->sync_fence_info. The second call pass the
> >>> +	 * num_fences value received in the first call.
> >>> +	 */
> >>> +	if (!in.num_fences)
> >>> +		goto no_fences;
> >>> +
> >>> +	size = sync_file->num_fences * sizeof(*fence_info);
> >>> +	if (in.len != size) {
> >>> +		ret = -EFAULT;
> >>> +		goto out;
> >>> +	}
> >> Maybe check for in.len < size, and set set to size?
> >>
> >>
> >>> -	len = sizeof(struct sync_file_info);
> >>> +	fence_info = kzalloc(size, GFP_KERNEL);
> >>> +	if (!fence_info) {
> >>> +		ret = -ENOMEM;
> >>> +		goto out;
> >>> +	}
> >>>  
> >>>  	for (i = 0; i < sync_file->num_fences; ++i) {
> >>>  		struct fence *fence = sync_file->cbs[i].fence;
> >>>  
> >>> -		ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
> >>> +		ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
> >>> +					   size - len);
> >>>  
> >>>  		if (ret < 0)
> >>>  			goto out;
> >>> @@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
> >>>  		len += ret;
> >>>  	}
> >>>  
> >>> +	if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
> >>> +		ret = -EFAULT;
> >>> +		goto out;
> >>> +	}
> >>> +
> >>>  	info->len = len;
> >>> +	info->sync_fence_info = (__u64) in.sync_fence_info;
> >>> +
> >>> +no_fences:
> >>> +	info->num_fences = sync_file->num_fences;
> >>>  
> >>> -	if (copy_to_user((void __user *)arg, info, len))
> >>> +	if (copy_to_user((void __user *)arg, info, sizeof(*info)))
> >>>  		ret = -EFAULT;
> >>>  	else
> >>>  		ret = 0;
> >>>  
> >>>  out:
> >>> +	kfree(fence_info);
> >>>  	kfree(info);
> >>>  
> >>>  	return ret;
> >>> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
> >>> index f0b41ce..9aad623 100644
> >>> --- a/drivers/staging/android/uapi/sync.h
> >>> +++ b/drivers/staging/android/uapi/sync.h
> >>> @@ -42,21 +42,20 @@ struct sync_fence_info {
> >>>  
> >>>  /**
> >>>   * struct sync_file_info - data returned from fence info ioctl
> >>> - * @len:	ioctl caller writes the size of the buffer its passing in.
> >>> - *		ioctl returns length of sync_file_info returned to
> >>> - *		userspace including pt_info.
> >>>   * @name:	name of fence
> >>>   * @status:	status of fence. 1: signaled 0:active <0:error
> >>>   * @num_fences	number of fences in the sync_file
> >>> + * @len:	ioctl caller writes the size of the buffer its passing in.
> >>> + *		ioctl returns length of all fence_infos summed.
> >>>   * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
> >>>   */
> >>>  struct sync_file_info {
> >>> -	__u32	len;
> >>>  	char	name[32];
> >>>  	__s32	status;
> >>>  	__u32	num_fences;
> >>> +	__u32	len;
> >>>  
> >>> -	__u8	sync_fence_info[0];
> >>> +	__u64	sync_fence_info;
> >>>  };
> >>>  
> >>>  #define SYNC_IOC_MAGIC		'>'
> >> Not sure if len adds anything here, userspace knows to allocate num_fences * sizeof(struct sync_fence_info);
> > I think of len being useful if we decide to extend struct sync_fence_info in
> > the future, so we may use len to help discover the size of each
> > sync_fence_info. What do you think?
> >
> I don't think you could extend it arbitrarily, you could make userspace pass a flag to indicate the struct is extended, so kernel space can choose
> whether to use the bigger size struct or not.
> 
> something like sync_file_info.flags = FENCE_INFO_V2; -- kernel can reject with -EINVAL if unsupported, or fill in a v2 struct.

Fair enough, I'll just remove len then.

	Gustavo