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 --- 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]; };
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 --- 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 */
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 --- 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; };
/**
Op 26-02-16 om 19:31 schreef 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
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;
};
/**
For the first 3 patches:
Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com
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 '>'
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 '>'
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
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
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
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
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
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
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
On Fri, Feb 26, 2016 at 03:31:46PM -0300, Gustavo Padovan wrote:
+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;
We need to kfree(fence_info) here.
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
The documentation needs updating.
*/ 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;
};
regards, dan carpenter
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)
Signed-off-by: Gustavo Padovan gustavo.padovan@collabora.co.uk --- drivers/staging/android/sync.c | 7 ++++++- drivers/staging/android/uapi/sync.h | 6 ++++++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 837cff5..54fd5ab 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 = -EFAULT; + goto err_put_fd; + } + fence2 = sync_file_fdget(data.fd2); if (!fence2) { err = -ENOENT; @@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, if (copy_from_user(&in, (void __user *)arg, sizeof(*info))) return -EFAULT;
- if (in.status || strcmp(in.name, "\0")) + if (in.status || in.flags || strcmp(in.name, "\0")) return -EFAULT;
if (in.num_fences && !in.sync_fence_info) diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h index 9aad623..f56a6c2 100644 --- a/drivers/staging/android/uapi/sync.h +++ b/drivers/staging/android/uapi/sync.h @@ -19,11 +19,13 @@ * @fd2: file descriptor of second fence * @name: name of new fence * @fence: returns the fd of the new fence to userspace + * @flags: merge_data flags */ struct sync_merge_data { __s32 fd2; char name[32]; __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,6 +48,7 @@ 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 * @len: ioctl caller writes the size of the buffer its passing in. * ioctl returns length of all fence_infos summed. @@ -52,6 +57,7 @@ struct sync_fence_info { struct sync_file_info { char name[32]; __s32 status; + __u32 flags; __u32 num_fences; __u32 len;
Hi Gustavo,
On 26 February 2016 at 18:31, Gustavo Padovan gustavo@padovan.org 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)
Signed-off-by: Gustavo Padovan gustavo.padovan@collabora.co.uk
drivers/staging/android/sync.c | 7 ++++++- drivers/staging/android/uapi/sync.h | 6 ++++++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 837cff5..54fd5ab 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 = -EFAULT;
-EINVAL ?
goto err_put_fd;}fence2 = sync_file_fdget(data.fd2); if (!fence2) { err = -ENOENT;@@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, if (copy_from_user(&in, (void __user *)arg, sizeof(*info))) return -EFAULT;
if (in.status || strcmp(in.name, "\0"))
if (in.status || in.flags || strcmp(in.name, "\0")) return -EFAULT;
-EINVAL ?
if (in.num_fences && !in.sync_fence_info)diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h index 9aad623..f56a6c2 100644 --- a/drivers/staging/android/uapi/sync.h +++ b/drivers/staging/android/uapi/sync.h @@ -19,11 +19,13 @@
- @fd2: file descriptor of second fence
- @name: name of new fence
- @fence: returns the fd of the new fence to userspace
*/
- @flags: merge_data flags
struct sync_merge_data { __s32 fd2; char name[32]; __s32 fence;
__u32 flags;
The overall size of the struct is not multiple of 64bit, so things will end up badly if we decide to extend it in the future. Even if there's a small chance that update will be needed, we might as well pad it now (and check the padding for zero, returning -EINVAL).
};
/** @@ -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;
Should we be doing some form of validation in sync_fill_fence_info() of 'flags' ?
Regards, Emil
Hi Emil,
2016-02-27 Emil Velikov emil.l.velikov@gmail.com:
Hi Gustavo,
On 26 February 2016 at 18:31, Gustavo Padovan gustavo@padovan.org 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)
Signed-off-by: Gustavo Padovan gustavo.padovan@collabora.co.uk
drivers/staging/android/sync.c | 7 ++++++- drivers/staging/android/uapi/sync.h | 6 ++++++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 837cff5..54fd5ab 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 = -EFAULT;-EINVAL ?
goto err_put_fd;}fence2 = sync_file_fdget(data.fd2); if (!fence2) { err = -ENOENT;@@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, if (copy_from_user(&in, (void __user *)arg, sizeof(*info))) return -EFAULT;
if (in.status || strcmp(in.name, "\0"))
if (in.status || in.flags || strcmp(in.name, "\0")) return -EFAULT;-EINVAL ?
if (in.num_fences && !in.sync_fence_info)diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h index 9aad623..f56a6c2 100644 --- a/drivers/staging/android/uapi/sync.h +++ b/drivers/staging/android/uapi/sync.h @@ -19,11 +19,13 @@
- @fd2: file descriptor of second fence
- @name: name of new fence
- @fence: returns the fd of the new fence to userspace
*/
- @flags: merge_data flags
struct sync_merge_data { __s32 fd2; char name[32]; __s32 fence;
__u32 flags;The overall size of the struct is not multiple of 64bit, so things will end up badly if we decide to extend it in the future. Even if there's a small chance that update will be needed, we might as well pad it now (and check the padding for zero, returning -EINVAL).
I think name could be the first field here.
};
/** @@ -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;Should we be doing some form of validation in sync_fill_fence_info() of 'flags' ?
Do you think it is necessary? The kernel allocates a zero'ed buffer to fill sync_fence_info array.
Gustavo
On 27 February 2016 at 15:27, 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 18:31, Gustavo Padovan gustavo@padovan.org 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)
Signed-off-by: Gustavo Padovan gustavo.padovan@collabora.co.uk
drivers/staging/android/sync.c | 7 ++++++- drivers/staging/android/uapi/sync.h | 6 ++++++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 837cff5..54fd5ab 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 = -EFAULT;-EINVAL ?
goto err_put_fd;}fence2 = sync_file_fdget(data.fd2); if (!fence2) { err = -ENOENT;@@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, if (copy_from_user(&in, (void __user *)arg, sizeof(*info))) return -EFAULT;
if (in.status || strcmp(in.name, "\0"))
if (in.status || in.flags || strcmp(in.name, "\0")) return -EFAULT;-EINVAL ?
if (in.num_fences && !in.sync_fence_info)diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h index 9aad623..f56a6c2 100644 --- a/drivers/staging/android/uapi/sync.h +++ b/drivers/staging/android/uapi/sync.h @@ -19,11 +19,13 @@
- @fd2: file descriptor of second fence
- @name: name of new fence
- @fence: returns the fd of the new fence to userspace
*/
- @flags: merge_data flags
struct sync_merge_data { __s32 fd2; char name[32]; __s32 fence;
__u32 flags;The overall size of the struct is not multiple of 64bit, so things will end up badly if we decide to extend it in the future. Even if there's a small chance that update will be needed, we might as well pad it now (and check the padding for zero, returning -EINVAL).
I think name could be the first field here.
Up-to you really. I'm afraid that it doesn't resolve the issue :-( As a test add a u64 value at the end of the struct and check the output of pahole for 32 and 64 bit build.
};
/** @@ -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;Should we be doing some form of validation in sync_fill_fence_info() of 'flags' ?
Do you think it is necessary? The kernel allocates a zero'ed buffer to fill sync_fence_info array.
Good point. Missed out the z in kzalloc :-)
-Emil
Op 26-02-16 om 19:31 schreef 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)
Signed-off-by: Gustavo Padovan gustavo.padovan@collabora.co.uk
drivers/staging/android/sync.c | 7 ++++++- drivers/staging/android/uapi/sync.h | 6 ++++++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 837cff5..54fd5ab 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 = -EFAULT;goto err_put_fd;- }
-EINVAL
fence2 = sync_file_fdget(data.fd2); if (!fence2) { err = -ENOENT; @@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, if (copy_from_user(&in, (void __user *)arg, sizeof(*info))) return -EFAULT;
- if (in.status || strcmp(in.name, "\0"))
- if (in.status || in.flags || strcmp(in.name, "\0")) return -EFAULT;
-EINVAL
if (in.num_fences && !in.sync_fence_info) diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h index 9aad623..f56a6c2 100644 --- a/drivers/staging/android/uapi/sync.h +++ b/drivers/staging/android/uapi/sync.h @@ -19,11 +19,13 @@
- @fd2: file descriptor of second fence
- @name: name of new fence
- @fence: returns the fd of the new fence to userspace
*/
- @flags: merge_data flags
struct sync_merge_data { __s32 fd2; char name[32]; __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,6 +48,7 @@ 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
- @len: ioctl caller writes the size of the buffer its passing in.
ioctl returns length of all fence_infos summed.@@ -52,6 +57,7 @@ struct sync_fence_info { struct sync_file_info { char name[32]; __s32 status;
- __u32 flags; __u32 num_fences; __u32 len;
This breaks userspace. You used to be able to figure it out from info->len - sizeof(struct sync_file_info).
regards, dan carpenter
2016-03-01 Dan Carpenter dan.carpenter@oracle.com:
This breaks userspace. You used to be able to figure it out from info->len - sizeof(struct sync_file_info).
It does. We are breaking this on purpose to clean up the API for de-staging.
Gustavo
dri-devel@lists.freedesktop.org
-
Dan Carpenter -
Emil Velikov -
Gustavo Padovan -
Gustavo Padovan -
Maarten Lankhorst