All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org,
	"Daniel Stone" <daniels@collabora.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Riley Andrews" <riandrews@android.com>,
	"ML dri-devel" <dri-devel@lists.freedesktop.org>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [PATCH v5 5/5] staging/android: add flags member to sync ioctl structs
Date: Wed, 2 Mar 2016 09:38:34 +0000	[thread overview]
Message-ID: <CACvgo50tLFe-GdiV1fP_C8M-pg9p=WqO+HC4UprY8jfks-2xzA@mail.gmail.com> (raw)
In-Reply-To: <1456837981-31584-5-git-send-email-gustavo@padovan.org>

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/Documentation/ioctl/botching-up-ioctls.txt#n37
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt#n32

WARNING: multiple messages have this Message-ID (diff)
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: devel@driverdev.osuosl.org,
	"Daniel Stone" <daniels@collabora.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	"ML dri-devel" <dri-devel@lists.freedesktop.org>,
	"Riley Andrews" <riandrews@android.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [PATCH v5 5/5] staging/android: add flags member to sync ioctl structs
Date: Wed, 2 Mar 2016 09:38:34 +0000	[thread overview]
Message-ID: <CACvgo50tLFe-GdiV1fP_C8M-pg9p=WqO+HC4UprY8jfks-2xzA@mail.gmail.com> (raw)
In-Reply-To: <1456837981-31584-5-git-send-email-gustavo@padovan.org>

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/Documentation/ioctl/botching-up-ioctls.txt#n37
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt#n32
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-03-02  9:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 13:12 [PATCH v5 1/5] staging/android: add num_fences field to struct sync_file_info Gustavo Padovan
2016-03-01 13:12 ` Gustavo Padovan
2016-03-01 13:12 ` [PATCH v5 2/5] staging/android: rename SYNC_IOC_FENCE_INFO Gustavo Padovan
2016-03-01 13:12   ` Gustavo Padovan
2016-03-01 13:12 ` [PATCH v5 3/5] staging/android: remove redundant comments on sync_merge_data Gustavo Padovan
2016-03-01 13:12   ` Gustavo Padovan
2016-03-01 13:13 ` [PATCH v5 4/5] staging/android: refactor SYNC_IOC_FILE_INFO Gustavo Padovan
2016-03-01 13:13   ` Gustavo Padovan
2016-03-01 13:13 ` [PATCH v5 5/5] staging/android: add flags member to sync ioctl structs Gustavo Padovan
2016-03-01 13:13   ` Gustavo Padovan
2016-03-02  9:38   ` Emil Velikov [this message]
2016-03-02  9:38     ` Emil Velikov
2016-03-02 19:50     ` Gustavo Padovan
2016-03-02 19:50       ` Gustavo Padovan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACvgo50tLFe-GdiV1fP_C8M-pg9p=WqO+HC4UprY8jfks-2xzA@mail.gmail.com' \
    --to=emil.l.velikov@gmail.com \
    --cc=John.C.Harrison@intel.com \
    --cc=arve@android.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=gustavo@padovan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riandrews@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.