On 1 March 2016 at 13:13, 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)
v3: return -EINVAL if flags are not zero'ed
Signed-off-by: Gustavo Padovan gustavo.padovan@collabora.co.uk
drivers/staging/android/sync.c | 8 ++++++++ drivers/staging/android/uapi/sync.h | 6 ++++++ 2 files changed, 14 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 3604e453..3c265ed 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)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..11e2d28 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 comment from last round still stands, struct size must be multiple of 64bits. As is the struct will be broken whenever/if we decide to extend it. See [1] for an alternative wording.
};
/** @@ -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
- @sync_fence_info: pointer to array of structs sync_fence_info with all
fences in the sync_file@@ -51,6 +56,7 @@ struct sync_fence_info { struct sync_file_info { char name[32]; __s32 status;
__u32 flags; __u32 num_fences; __u64 sync_fence_info;
Thanks for taking my suggestion and dropping len. Although I fear that we introduced a hole which we should be explicitly padded [2].
In both cases the pad should be checked for 0 and -EINVAL should be returned if that's not the case. This will allow us to potentially reuse in the future.
Other than that I believe the series looks pretty much spot on.
Cheers, Emil
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen... [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen...