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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gustavo,

On 26 February 2016 at 18:31, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote:
> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx>
> ---
>  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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux