On Fri, May 12, 2017 at 10:34:55AM +1000, Dave Airlie wrote: > From: Dave Airlie <airlied at 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 <airlied at 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 at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch