On Fri, May 12, 2017 at 10:34:55AM +1000, Dave Airlie wrote:
> From: Dave Airlie <airl...@redhat.com>
>
> This interface allows importing the fence from a sync_file into
> an existing drm sync object, or exporting the fence attached to
> an existing drm sync object into a new sync file object.
>
> This should only be used to interact with sync files where necessary.
>
> Signed-off-by: Dave Airlie <airl...@redhat.com>
A bunch of nits around ioctl validation and stuff. lgtm otherwise, ack
with those addressed.
-Daniel
> ---
> drivers/gpu/drm/drm_syncobj.c | 56
> +++++++++++++++++++++++++++++++++++++++++++
> include/uapi/drm/drm.h | 6 +++--
> 2 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 9a8c690..69ef20a 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -52,6 +52,7 @@
> #include <linux/file.h>
> #include <linux/fs.h>
> #include <linux/anon_inodes.h>
> +#include <linux/sync_file.h>
>
> #include "drm_internal.h"
> #include <drm/drm_syncobj.h>
> @@ -290,6 +291,48 @@ static int drm_syncobj_fd_to_handle(struct drm_file
> *file_private,
> return 0;
> }
>
> +int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
> + int fd, int handle)
> +{
> + struct dma_fence *fence = sync_file_get_fence(fd);
> + if (!fence)
> + return -EINVAL;
> +
> + return drm_syncobj_replace_fence(file_private, handle, fence);
> +}
> +
> +int drm_syncobj_export_sync_file(struct drm_file *file_private,
> + int handle, int *p_fd)
> +{
> + int ret;
> + struct dma_fence *fence;
> + struct sync_file *sync_file;
> + int fd = get_unused_fd_flags(O_CLOEXEC);
I guess the idea was to use args->fd_flags here?
> +
> + if (fd < 0)
> + return fd;
> +
> + ret = drm_syncobj_fence_get(file_private, handle, &fence);
> + if (ret)
> + goto err_put_fd;
> +
> + sync_file = sync_file_create(fence);
> + if (!sync_file) {
> + ret = -EINVAL;
> + goto err_fence_put;
> + }
> +
> + fd_install(fd, sync_file->file);
> +
> + dma_fence_put(fence);
> + *p_fd = fd;
> + return 0;
> +err_fence_put:
> + dma_fence_put(fence);
> +err_put_fd:
> + put_unused_fd(fd);
> + return ret;
> +}
> /**
> * drm_syncobj_open - initalizes syncobj file-private structures at devnode
> open time
> * @dev: drm_device which is being opened by userspace
> @@ -372,6 +415,12 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
> void *data,
> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> return -ENODEV;
>
> + if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
> + return drm_syncobj_export_sync_file(file_private, args->handle,
> + &args->fd);
Checks like in the wait ioctl that no other flags are set is missing in
both callbacks.
> + else if (args->flags)
> + return -EINVAL;
> +
> return drm_syncobj_handle_to_fd(file_private, args->handle,
> &args->fd);
> }
> @@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
> void *data,
> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> return -ENODEV;
>
> + if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE)
> + return drm_syncobj_import_sync_file_fence(file_private,
> + args->fd,
> + args->handle);
> + else if (args->flags)
> + return -EINVAL;
> +
> return drm_syncobj_fd_to_handle(file_private, args->fd,
> &args->handle);
> }
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index db9e35e..d0e05f4 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -707,13 +707,15 @@ struct drm_syncobj_destroy {
> __u32 pad;
> };
>
> +#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE (1 << 0)
> +#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE (1 << 0)
> struct drm_syncobj_handle {
> __u32 handle;
> /** Flags.. only applicable for handle->fd */
> - __u32 flags;
> + __u32 fd_flags;
>
> __s32 fd;
> - __u32 pad;
> + __u32 flags;
s/pad/fd_flags/ instead of the shuffle you've done here I presume?
Also I didn't spot any fd_flags validation anywhere.
> };
>
> /* timeout_ns is relative timeout in nanoseconds */
> --
> 2.9.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
