Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
Signed-off-by: Jason Ekstrand jason@jlekstrand.net ---
This is marked as an RFC because I intend it to start a discussion about how to solve a problem. The current patch compiles but that's it for now. I'll be writing IGT tests and Vulkan driver patches which exercise it over the next couple of days. In the mean time, feel free to tell me why you think this is a great and/or terrible idea. :-)
--Jason
drivers/dma-buf/dma-buf.c | 115 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 +++- 2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..3845b87e209e 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,114 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + dma_resv_add_excl_fence(dmabuf->resv, fence); + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + return 0; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + struct dma_fence **fences = NULL; + unsigned i, num_fences = 0; + + ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL, + &num_fences, &fences); + if (ret) + goto err_put_fd; + + if (num_fences == 0) { + fence = dma_fence_get_stub(); + } else if (num_fences == 1) { + fence = fences[0]; + kfree(fences); + } else { + struct dma_fence_array *fence_arr; + + fence_arr = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!fence_arr) { + for (i = 0; i < num_fences; i++) + dma_fence_put(fences[i]); + kfree(fences); + ret = -ENOMEM; + goto err_put_fd; + } + + /* The fence array now owns fences_arr and our + * references to each of the individual fences. We + * only own a reference to the one array fence. + */ + fence = &fence_arr->base; + } + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + if (!fence) + fence = dma_fence_get_stub(); + } + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +499,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
+ case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..825b9a913c89 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
Hi Jason,
Am 26.02.20 um 00:58 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
This is marked as an RFC because I intend it to start a discussion about how to solve a problem. The current patch compiles but that's it for now. I'll be writing IGT tests and Vulkan driver patches which exercise it over the next couple of days. In the mean time, feel free to tell me why you think this is a great and/or terrible idea. :-)
For the exporting part I think it is an absolutely great idea because it simplifies compatibility with explicit sync quite a bit.
But for the importing part it is a clear NAK at the moment. See we can't allow userspace to mess with DMA-buf fences in that way because it rips open a security hole you can push an elephant through.
Just imagine that you access some DMA-buf with a shader and that operation is presented as a fence on the DMA-bufs reservation object. And now you can go ahead and replace that fence and free up the memory.
Tricking the Linux kernel into allocating page tables in that freed memory is trivial and that's basically it you can overwrite page tables with your shader and gain access to all of system memory :)
What we could do is to always make sure that the added fences will complete later than the already existing ones, but that is also rather tricky to get right. I wouldn't do that if we don't have a rather big use case for this.
Regards, Christian.
--Jason
[SNIP]
On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote:
Hi Jason,
Am 26.02.20 um 00:58 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
This is marked as an RFC because I intend it to start a discussion about how to solve a problem. The current patch compiles but that's it for now. I'll be writing IGT tests and Vulkan driver patches which exercise it over the next couple of days. In the mean time, feel free to tell me why you think this is a great and/or terrible idea. :-)
For the exporting part I think it is an absolutely great idea because it simplifies compatibility with explicit sync quite a bit.
But for the importing part it is a clear NAK at the moment. See we can't allow userspace to mess with DMA-buf fences in that way because it rips open a security hole you can push an elephant through.
Just imagine that you access some DMA-buf with a shader and that operation is presented as a fence on the DMA-bufs reservation object. And now you can go ahead and replace that fence and free up the memory.
Tricking the Linux kernel into allocating page tables in that freed memory is trivial and that's basically it you can overwrite page tables with your shader and gain access to all of system memory :)
What we could do is to always make sure that the added fences will complete later than the already existing ones, but that is also rather tricky to get right. I wouldn't do that if we don't have a rather big use case for this.
I think the main use-case for adding a fence is adding a write fence for vk winsys buffers, which run without any sync at all. So essentially what we'd do is promote one of the read fences which are already attached to be the write fence.
But yeah making sure we don't break any of the dma_resv guarantees about how these fences works is going to be somewhat tricky. Probably can reuse a big chunk of the fence container work we've done for syncobj timelines, since they have some of the same issues of having to chain fences to not break the world. -Daniel
Regards, Christian.
--Jason
[SNIP]
On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote:
Hi Jason,
Am 26.02.20 um 00:58 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
This is marked as an RFC because I intend it to start a discussion about how to solve a problem. The current patch compiles but that's it for now. I'll be writing IGT tests and Vulkan driver patches which exercise it over the next couple of days. In the mean time, feel free to tell me why you think this is a great and/or terrible idea. :-)
For the exporting part I think it is an absolutely great idea because it simplifies compatibility with explicit sync quite a bit.
Unfortunately, it only helps half of explicit sync and not the half that's hard to deal with from Vulkan. :-/
But for the importing part it is a clear NAK at the moment. See we can't allow userspace to mess with DMA-buf fences in that way because it rips open a security hole you can push an elephant through.
Oh, sure, I'm 100% sure I did that part wrong. Why else would I send the patch but to have someone who actually knows what they're doing tell me how to do it correctly? :-P
Just imagine that you access some DMA-buf with a shader and that operation is presented as a fence on the DMA-bufs reservation object. And now you can go ahead and replace that fence and free up the memory.
Tricking the Linux kernel into allocating page tables in that freed memory is trivial and that's basically it you can overwrite page tables with your shader and gain access to all of system memory :)
What we could do is to always make sure that the added fences will complete later than the already existing ones, but that is also rather tricky to get right. I wouldn't do that if we don't have a rather big use case for this.
Right. I thought about that but I'm still learning how dma_resv works. It'd be easy enough to make a fence array that contains both the old fence and the new fence and replace the old fence with that. What I don't know is the proper way to replace the exclusive fence safely. Some sort of atomic_cpxchg loop, perhaps? I presume there's some way of doing it properly because DRM drivers are doing it all the time.
I think the main use-case for adding a fence is adding a write fence for vk winsys buffers, which run without any sync at all. So essentially what we'd do is promote one of the read fences which are already attached to be the write fence.
Correct. We're effectively doing an import in ANV today but we're doing it with a dummy execbuf which claims to write the BO and has a batch that's just MI_BATCH_BUFFER_END.
But yeah making sure we don't break any of the dma_resv guarantees about how these fences works is going to be somewhat tricky. Probably can reuse a big chunk of the fence container work we've done for syncobj timelines, since they have some of the same issues of having to chain fences to not break the world.
Happy to not break the world. I just don't know how yet. :-)
--Jason
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
Signed-off-by: Jason Ekstrand jason@jlekstrand.net --- drivers/dma-buf/dma-buf.c | 162 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++- 2 files changed, 173 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..162f90e8896b 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,161 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+/* This function takes a ref to add_fence on success. The caller still + * owns its ref and has to dma_fence_put it. + */ +static struct dma_fence *dma_buf_get_unified_fence(struct dma_buf *dmabuf, + struct dma_fence *add_fence) +{ + struct dma_fence **fences = NULL; + struct dma_fence_array *array; + unsigned i, num_fences = 0; + int ret; + + ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL, + &num_fences, &fences); + if (ret) + return NULL; /* ret can only be 0 or -ENOMEM */ + + if (num_fences == 0) { + if (add_fence) { + return add_fence; + } else { + return dma_fence_get_stub(); + } + } else if (num_fences == 1 && (!add_fence || add_fence == fences[0])) { + struct dma_fence *fence = fences[0]; + kfree(fences); + return fence; + } + + if (add_fence) { + struct dma_fence **nfences; + size_t sz; + + /* Get a ref to add_fence so that we have a ref to every + * fence we are going to put in the array. + */ + dma_fence_get(add_fence); + + sz = (num_fences + 1) * sizeof(*fences); + nfences = krealloc(fences, sz, GFP_NOWAIT | __GFP_NOWARN); + if (!nfences) + goto err_put_fences; + + nfences[num_fences++] = add_fence; + } + + array = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!array) + goto err_put_fences; + + /* The fence array now owns fences_arr and our references to each + * of the individual fences. We only own a reference to the one + * array fence. + */ + + return &array->base; + +err_put_fences: + for (i = 0; i < num_fences; i++) + dma_fence_put(fences[0]); + dma_fence_put(add_fence); + kfree(fences); + return NULL; +} + +static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence, *unified_fence; + int ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + dma_resv_lock(dmabuf->resv, NULL); + unified_fence = dma_buf_get_unified_fence(dmabuf, fence); + if (unified_fence) + dma_resv_add_excl_fence(dmabuf->resv, fence); + else + ret = -ENOMEM; + dma_resv_unlock(dmabuf->resv); + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + dma_fence_put(fence); + + return ret; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + fence = dma_buf_get_unified_fence(dmabuf, NULL); + if (!fence) { + ret = -ENOMEM; + goto err_put_fd; + } + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + if (!fence) + fence = dma_fence_get_stub(); + } + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +546,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
+ case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..825b9a913c89 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand): - Lock around setting shared fences as well as exclusive - Mark SIGNAL_SYNC_FILE as a read-write ioctl. - Initialize ret to 0 in dma_buf_wait_sync_file
Signed-off-by: Jason Ekstrand jason@jlekstrand.net --- drivers/dma-buf/dma-buf.c | 164 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++- 2 files changed, 175 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..2c4608bae3c2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,163 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+/* This function takes a ref to add_fence on success. The caller still + * owns its ref and has to dma_fence_put it. + */ +static struct dma_fence *dma_buf_get_unified_fence(struct dma_buf *dmabuf, + struct dma_fence *add_fence) +{ + struct dma_fence **fences = NULL; + struct dma_fence_array *array; + unsigned i, num_fences = 0; + int ret; + + ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL, + &num_fences, &fences); + if (ret) + return NULL; /* ret can only be 0 or -ENOMEM */ + + if (num_fences == 0) { + if (add_fence) { + return add_fence; + } else { + return dma_fence_get_stub(); + } + } else if (num_fences == 1 && (!add_fence || add_fence == fences[0])) { + struct dma_fence *fence = fences[0]; + kfree(fences); + return fence; + } + + if (add_fence) { + struct dma_fence **nfences; + size_t sz; + + /* Get a ref to add_fence so that we have a ref to every + * fence we are going to put in the array. + */ + dma_fence_get(add_fence); + + sz = (num_fences + 1) * sizeof(*fences); + nfences = krealloc(fences, sz, GFP_NOWAIT | __GFP_NOWARN); + if (!nfences) + goto err_put_fences; + + nfences[num_fences++] = add_fence; + } + + array = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!array) + goto err_put_fences; + + /* The fence array now owns fences_arr and our references to each + * of the individual fences. We only own a reference to the one + * array fence. + */ + + return &array->base; + +err_put_fences: + for (i = 0; i < num_fences; i++) + dma_fence_put(fences[0]); + dma_fence_put(add_fence); + kfree(fences); + return NULL; +} + +static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence, *unified_fence; + int ret = 0; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + dma_resv_lock(dmabuf->resv, NULL); + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + unified_fence = dma_buf_get_unified_fence(dmabuf, fence); + if (unified_fence) + dma_resv_add_excl_fence(dmabuf->resv, fence); + else + ret = -ENOMEM; + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + dma_resv_unlock(dmabuf->resv); + + dma_fence_put(fence); + + return ret; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + fence = dma_buf_get_unified_fence(dmabuf, NULL); + if (!fence) { + ret = -ENOMEM; + goto err_put_fd; + } + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + if (!fence) + fence = dma_fence_get_stub(); + } + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +548,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
+ case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..86e07acca90c 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
Vulkan WSI user of the new API:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037
On Tue, Mar 3, 2020 at 1:03 PM Jason Ekstrand jason@jlekstrand.net wrote:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
drivers/dma-buf/dma-buf.c | 164 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++- 2 files changed, 175 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..2c4608bae3c2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,163 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+/* This function takes a ref to add_fence on success. The caller still
- owns its ref and has to dma_fence_put it.
- */
+static struct dma_fence *dma_buf_get_unified_fence(struct dma_buf *dmabuf,
struct dma_fence *add_fence)+{
struct dma_fence **fences = NULL;struct dma_fence_array *array;unsigned i, num_fences = 0;int ret;ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL,&num_fences, &fences);if (ret)return NULL; /* ret can only be 0 or -ENOMEM */if (num_fences == 0) {if (add_fence) {return add_fence;} else {return dma_fence_get_stub();}} else if (num_fences == 1 && (!add_fence || add_fence == fences[0])) {struct dma_fence *fence = fences[0];kfree(fences);return fence;}if (add_fence) {struct dma_fence **nfences;size_t sz;/* Get a ref to add_fence so that we have a ref to every* fence we are going to put in the array.*/dma_fence_get(add_fence);sz = (num_fences + 1) * sizeof(*fences);nfences = krealloc(fences, sz, GFP_NOWAIT | __GFP_NOWARN);if (!nfences)goto err_put_fences;nfences[num_fences++] = add_fence;}array = dma_fence_array_create(num_fences, fences,dma_fence_context_alloc(1),1, false);if (!array)goto err_put_fences;/* The fence array now owns fences_arr and our references to each* of the individual fences. We only own a reference to the one* array fence.*/return &array->base;+err_put_fences:
for (i = 0; i < num_fences; i++)dma_fence_put(fences[0]);dma_fence_put(add_fence);kfree(fences);return NULL;+}
+static long dma_buf_wait_sync_file(struct dma_buf *dmabuf,
const void __user *user_data)+{
struct dma_buf_sync_file arg;struct dma_fence *fence, *unified_fence;int ret = 0;if (copy_from_user(&arg, user_data, sizeof(arg)))return -EFAULT;if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)return -EINVAL;fence = sync_file_get_fence(arg.fd);if (!fence)return -EINVAL;dma_resv_lock(dmabuf->resv, NULL);if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {unified_fence = dma_buf_get_unified_fence(dmabuf, fence);if (unified_fence)dma_resv_add_excl_fence(dmabuf->resv, fence);elseret = -ENOMEM;} else {dma_resv_add_shared_fence(dmabuf->resv, fence);}dma_resv_unlock(dmabuf->resv);dma_fence_put(fence);return ret;+}
+static long dma_buf_signal_sync_file(struct dma_buf *dmabuf,
void __user *user_data)+{
struct dma_buf_sync_file arg;struct dma_fence *fence = NULL;struct sync_file *sync_file;int fd, ret;if (copy_from_user(&arg, user_data, sizeof(arg)))return -EFAULT;if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)return -EINVAL;fd = get_unused_fd_flags(O_CLOEXEC);if (fd < 0)return fd;if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {/* We need to include both the exclusive fence and all of* the shared fences in our fence.*/fence = dma_buf_get_unified_fence(dmabuf, NULL);if (!fence) {ret = -ENOMEM;goto err_put_fd;}} else {fence = dma_resv_get_excl_rcu(dmabuf->resv);if (!fence)fence = dma_fence_get_stub();}sync_file = sync_file_create(fence);dma_fence_put(fence);if (!sync_file) {ret = -EINVAL;goto err_put_fd;}fd_install(fd, sync_file->file);arg.fd = fd;if (copy_to_user(user_data, &arg, sizeof(arg)))return -EFAULT;return 0;+err_put_fd:
put_unused_fd(fd);return ret;+}
static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +548,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
case DMA_BUF_IOCTL_WAIT_SYNC_FILE:return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg);case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE:return dma_buf_signal_sync_file(dmabuf, (void __user *)arg);default: return -ENOTTY; }diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..86e07acca90c 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file {
__u32 flags;__s32 fd;+};
+#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0)
#define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
2.24.1
From: Christian König ckoenig.leichtzumerken@gmail.com
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand) - Return NULL from dma_fence_array_first if head == NULL. This matches the iterator behavior of dma_fence_chain_for_each in that it iterates zero times if head == NULL. - Return NULL from dma_fence_array_next if index > array->num_fences.
Signed-off-by: Jason Ekstrand jason@jlekstrand.net --- drivers/dma-buf/dma-fence-array.c | 27 +++++++++++++++++++++++++++ include/linux/dma-fence-array.h | 17 +++++++++++++++++ 2 files changed, 44 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index d3fbd950be94..2ac1afc697d0 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -201,3 +201,30 @@ bool dma_fence_match_context(struct dma_fence *fence, u64 context) return true; } EXPORT_SYMBOL(dma_fence_match_context); + +struct dma_fence *dma_fence_array_first(struct dma_fence *head) +{ + struct dma_fence_array *array; + + if (!head) + return NULL; + + array = to_dma_fence_array(head); + if (!array) + return head; + + return array->fences[0]; +} +EXPORT_SYMBOL(dma_fence_array_first); + +struct dma_fence *dma_fence_array_next(struct dma_fence *head, + unsigned int index) +{ + struct dma_fence_array *array = to_dma_fence_array(head); + + if (!array || index >= array->num_fences) + return NULL; + + return array->fences[index]; +} +EXPORT_SYMBOL(dma_fence_array_next); diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h index 303dd712220f..588ac8089dd6 100644 --- a/include/linux/dma-fence-array.h +++ b/include/linux/dma-fence-array.h @@ -74,6 +74,19 @@ to_dma_fence_array(struct dma_fence *fence) return container_of(fence, struct dma_fence_array, base); }
+/** + * dma_fence_array_for_each - iterate over all fences in array + * @fence: current fence + * @index: index into the array + * @head: potential dma_fence_array object + * + * Test if @array is a dma_fence_array object and if yes iterate over all fences + * in the array. If not just iterate over the fence in @array itself. + */ +#define dma_fence_array_for_each(fence, index, head) \ + for (index = 0, fence = dma_fence_array_first(head); fence; \ + ++(index), fence = dma_fence_array_next(head, index)) + struct dma_fence_array *dma_fence_array_create(int num_fences, struct dma_fence **fences, u64 context, unsigned seqno, @@ -81,4 +94,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences,
bool dma_fence_match_context(struct dma_fence *fence, u64 context);
+struct dma_fence *dma_fence_array_first(struct dma_fence *head); +struct dma_fence *dma_fence_array_next(struct dma_fence *head, + unsigned int index); + #endif /* __LINUX_DMA_FENCE_ARRAY_H */
From: Christian König ckoenig.leichtzumerken@gmail.com
Add a helper function to get a single fence representing all fences in a dma_resv object.
This fence is either the only one in the object or all not signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand): - Take reference of fences both for creating the dma_fence_array and in the case where we return one fence. - Handle the case where dma_resv_get_list() returns NULL
Signed-off-by: Jason Ekstrand jason@jlekstrand.net --- drivers/dma-buf/dma-resv.c | 118 +++++++++++++++++++++++++++++++++++++ include/linux/dma-resv.h | 3 + 2 files changed, 121 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 4264e64788c4..66591d8ab7ef 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -33,6 +33,8 @@ */
#include <linux/dma-resv.h> +#include <linux/dma-fence-chain.h> +#include <linux/dma-fence-array.h> #include <linux/export.h> #include <linux/sched/mm.h>
@@ -47,6 +49,19 @@ * write-side updates. */
+/** + * dma_fence_deep_dive_for_each - deep dive into the fence containers + * @fence: resulting fence + * @chain: variable for a dma_fence_chain + * @index: index into a dma_fence_array + * @head: starting point + * + * Helper to deep dive into the fence containers for flattening them. + */ +#define dma_fence_deep_dive_for_each(fence, chain, index, head) \ + dma_fence_chain_for_each(chain, head) \ + dma_fence_array_for_each(fence, index, chain) + DEFINE_WD_CLASS(reservation_ww_class); EXPORT_SYMBOL(reservation_ww_class);
@@ -516,6 +531,109 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj, } EXPORT_SYMBOL_GPL(dma_resv_get_fences_rcu);
+/** + * dma_resv_get_singleton - get a single fence for the dma_resv object + * @obj: the reservation object + * @extra: extra fence to add to the resulting array + * @result: resulting dma_fence + * + * Get a single fence representing all unsignaled fences in the dma_resv object + * plus the given extra fence. If we got only one fence return a new + * reference to that, otherwise return a dma_fence_array object. + * + * RETURNS + * Returns -NOMEM if allocations fail, zero otherwise. + */ +int dma_resv_get_singleton(struct dma_resv *obj, struct dma_fence *extra, + struct dma_fence **result) +{ + struct dma_resv_list *fobj = dma_resv_get_list(obj); + struct dma_fence *excl = dma_resv_get_excl(obj); + struct dma_fence *fence, *chain, **fences; + struct dma_fence_array *array; + unsigned int num_fences, shared_count; + unsigned int i, j; + + num_fences = 0; + *result = NULL; + + dma_fence_deep_dive_for_each(fence, chain, i, extra) { + if (dma_fence_is_signaled(fence)) + continue; + + *result = fence; + ++num_fences; + } + + dma_fence_deep_dive_for_each(fence, chain, i, excl) { + if (dma_fence_is_signaled(fence)) + continue; + + *result = fence; + ++num_fences; + } + + shared_count = fobj ? fobj->shared_count : 0; + for (i = 0; i < shared_count; ++i) { + struct dma_fence *f; + + f = rcu_dereference_protected(fobj->shared[i], + dma_resv_held(obj)); + dma_fence_deep_dive_for_each(fence, chain, j, f) { + if (dma_fence_is_signaled(fence)) + continue; + + *result = fence; + ++num_fences; + } + } + + if (num_fences <= 1) { + *result = dma_fence_get(*result); + return 0; + } + + fences = kmalloc_array(num_fences, sizeof(struct dma_fence*), + GFP_KERNEL); + if (!fences) + return -ENOMEM; + + num_fences = 0; + + dma_fence_deep_dive_for_each(fence, chain, i, extra) + if (!dma_fence_is_signaled(fence)) + fences[num_fences++] = dma_fence_get(fence); + + dma_fence_deep_dive_for_each(fence, chain, i, excl) + if (!dma_fence_is_signaled(fence)) + fences[num_fences++] = dma_fence_get(fence); + + for (i = 0; i < shared_count; ++i) { + struct dma_fence *f; + + f = rcu_dereference_protected(fobj->shared[i], + dma_resv_held(obj)); + dma_fence_deep_dive_for_each(fence, chain, j, f) + if (!dma_fence_is_signaled(fence)) + fences[num_fences++] = dma_fence_get(fence); + } + + array = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!array) + goto error_free; + + *result = &array->base; + return 0; + +error_free: + while (num_fences--) + dma_fence_put(fences[num_fences]); + kfree(fences); + return -ENOMEM; +} + /** * dma_resv_wait_timeout_rcu - Wait on reservation's objects * shared and/or exclusive fences. diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index ee50d10f052b..d50e753e4550 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -287,6 +287,9 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
+int dma_resv_get_singleton(struct dma_resv *obj, struct dma_fence *extra, + struct dma_fence **result); + long dma_resv_wait_timeout_rcu(struct dma_resv *obj, bool wait_all, bool intr, unsigned long timeout);
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand): - Lock around setting shared fences as well as exclusive - Mark SIGNAL_SYNC_FILE as a read-write ioctl. - Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand): - Use the new dma_resv_get_singleton helper
Signed-off-by: Jason Ekstrand jason@jlekstrand.net --- drivers/dma-buf/dma-buf.c | 96 ++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++++- 2 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..09973c689866 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,95 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence; + int ret = 0; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + dma_resv_lock(dmabuf->resv, NULL); + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + struct dma_fence *singleton = NULL; + ret = dma_resv_get_singleton(dmabuf->resv, fence, &singleton); + if (!ret && singleton) + dma_resv_add_excl_fence(dmabuf->resv, singleton); + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + dma_resv_unlock(dmabuf->resv); + + dma_fence_put(fence); + + return ret; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence); + if (ret) + goto err_put_fd; + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + } + + if (!fence) + fence = dma_fence_get_stub(); + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +480,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
+ case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..86e07acca90c 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
Am 11.03.20 um 04:43 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
drivers/dma-buf/dma-buf.c | 96 ++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++++- 2 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..09973c689866 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,95 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; } +static long dma_buf_wait_sync_file(struct dma_buf *dmabuf,
const void __user *user_data)+{
- struct dma_buf_sync_file arg;
- struct dma_fence *fence;
- int ret = 0;
- if (copy_from_user(&arg, user_data, sizeof(arg)))
return -EFAULT;- if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)
return -EINVAL;- fence = sync_file_get_fence(arg.fd);
- if (!fence)
return -EINVAL;- dma_resv_lock(dmabuf->resv, NULL);
- if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {
struct dma_fence *singleton = NULL;ret = dma_resv_get_singleton(dmabuf->resv, fence, &singleton);if (!ret && singleton)dma_resv_add_excl_fence(dmabuf->resv, singleton);- } else {
dma_resv_add_shared_fence(dmabuf->resv, fence);- }
You also need to create a singleton when adding a shared fences.
The problem is that shared fences must always signal after exclusive ones and you can't guarantee that for the fence you add here.
Regards, Christian.
- dma_resv_unlock(dmabuf->resv);
- dma_fence_put(fence);
- return ret;
+}
+static long dma_buf_signal_sync_file(struct dma_buf *dmabuf,
void __user *user_data)+{
- struct dma_buf_sync_file arg;
- struct dma_fence *fence = NULL;
- struct sync_file *sync_file;
- int fd, ret;
- if (copy_from_user(&arg, user_data, sizeof(arg)))
return -EFAULT;- if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)
return -EINVAL;- fd = get_unused_fd_flags(O_CLOEXEC);
- if (fd < 0)
return fd;- if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {
/* We need to include both the exclusive fence and all of* the shared fences in our fence.*/ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence);if (ret)goto err_put_fd;- } else {
fence = dma_resv_get_excl_rcu(dmabuf->resv);- }
- if (!fence)
fence = dma_fence_get_stub();- sync_file = sync_file_create(fence);
- dma_fence_put(fence);
- if (!sync_file) {
ret = -EINVAL;goto err_put_fd;- }
- fd_install(fd, sync_file->file);
- arg.fd = fd;
- if (copy_to_user(user_data, &arg, sizeof(arg)))
return -EFAULT;- return 0;
+err_put_fd:
- put_unused_fd(fd);
- return ret;
+}
- static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
@@ -390,6 +480,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
- case DMA_BUF_IOCTL_WAIT_SYNC_FILE:
return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg);- case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE:
return dma_buf_signal_sync_file(dmabuf, (void __user *)arg);- default: return -ENOTTY; }
diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..86e07acca90c 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync { #define DMA_BUF_NAME_LEN 32 +struct dma_buf_sync_file {
- __u32 flags;
- __s32 fd;
+};
+#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0)
- #define DMA_BUF_BASE 'b'
-#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync) #endif
On Wed, Mar 11, 2020 at 8:18 AM Christian König christian.koenig@amd.com wrote:
Am 11.03.20 um 04:43 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
drivers/dma-buf/dma-buf.c | 96 ++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++++- 2 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..09973c689866 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,95 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+static long dma_buf_wait_sync_file(struct dma_buf *dmabuf,
const void __user *user_data)+{
struct dma_buf_sync_file arg;struct dma_fence *fence;int ret = 0;if (copy_from_user(&arg, user_data, sizeof(arg)))return -EFAULT;if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)return -EINVAL;fence = sync_file_get_fence(arg.fd);if (!fence)return -EINVAL;dma_resv_lock(dmabuf->resv, NULL);if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {struct dma_fence *singleton = NULL;ret = dma_resv_get_singleton(dmabuf->resv, fence, &singleton);if (!ret && singleton)dma_resv_add_excl_fence(dmabuf->resv, singleton);} else {dma_resv_add_shared_fence(dmabuf->resv, fence);}You also need to create a singleton when adding a shared fences.
The problem is that shared fences must always signal after exclusive ones and you can't guarantee that for the fence you add here.
I'm beginning to think that I should just drop the flags and always wait on all fences and always take what's currently the "write" path. Otherwise, something's going to get it wrong somewhere. Thoughts?
Also, Michelle (added to CC) commented on IRC today that amdgpu does something with implicit sync fences where it sorts out the fences which affect one queue vs. others. He thought that stuffing fences in the dma-buf in this way might cause that to not work. Thoughts?
--Jason
Regards, Christian.
dma_resv_unlock(dmabuf->resv);dma_fence_put(fence);return ret;+}
+static long dma_buf_signal_sync_file(struct dma_buf *dmabuf,
void __user *user_data)+{
struct dma_buf_sync_file arg;struct dma_fence *fence = NULL;struct sync_file *sync_file;int fd, ret;if (copy_from_user(&arg, user_data, sizeof(arg)))return -EFAULT;if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)return -EINVAL;fd = get_unused_fd_flags(O_CLOEXEC);if (fd < 0)return fd;if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {/* We need to include both the exclusive fence and all of* the shared fences in our fence.*/ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence);if (ret)goto err_put_fd;} else {fence = dma_resv_get_excl_rcu(dmabuf->resv);}if (!fence)fence = dma_fence_get_stub();sync_file = sync_file_create(fence);dma_fence_put(fence);if (!sync_file) {ret = -EINVAL;goto err_put_fd;}fd_install(fd, sync_file->file);arg.fd = fd;if (copy_to_user(user_data, &arg, sizeof(arg)))return -EFAULT;return 0;+err_put_fd:
put_unused_fd(fd);return ret;+}
- static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
@@ -390,6 +480,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
case DMA_BUF_IOCTL_WAIT_SYNC_FILE:return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg);case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE:return dma_buf_signal_sync_file(dmabuf, (void __user *)arg);default: return -ENOTTY; }diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..86e07acca90c 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file {
__u32 flags;__s32 fd;+};
+#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0)
- #define DMA_BUF_BASE 'b'
-#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
Am 12.03.20 um 16:57 schrieb Jason Ekstrand:
On Wed, Mar 11, 2020 at 8:18 AM Christian König christian.koenig@amd.com wrote:
Am 11.03.20 um 04:43 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
Signed-off-by: Jason Ekstrand jason@jlekstrand.net
drivers/dma-buf/dma-buf.c | 96 ++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 ++++- 2 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..09973c689866 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,95 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+static long dma_buf_wait_sync_file(struct dma_buf *dmabuf,
const void __user *user_data)+{
struct dma_buf_sync_file arg;struct dma_fence *fence;int ret = 0;if (copy_from_user(&arg, user_data, sizeof(arg)))return -EFAULT;if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)return -EINVAL;fence = sync_file_get_fence(arg.fd);if (!fence)return -EINVAL;dma_resv_lock(dmabuf->resv, NULL);if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {struct dma_fence *singleton = NULL;ret = dma_resv_get_singleton(dmabuf->resv, fence, &singleton);if (!ret && singleton)dma_resv_add_excl_fence(dmabuf->resv, singleton);} else {dma_resv_add_shared_fence(dmabuf->resv, fence);}You also need to create a singleton when adding a shared fences.
The problem is that shared fences must always signal after exclusive ones and you can't guarantee that for the fence you add here.
I'm beginning to think that I should just drop the flags and always wait on all fences and always take what's currently the "write" path. Otherwise, something's going to get it wrong somewhere. Thoughts?
If that is sufficient for your use case then that is certainly the more defensive (e.g. less dangerous) approach.
Also, Michelle (added to CC) commented on IRC today that amdgpu does something with implicit sync fences where it sorts out the fences which affect one queue vs. others. He thought that stuffing fences in the dma-buf in this way might cause that to not work. Thoughts?
Yes that is correct. What amdgpu does is it ignores all fences from the same process.
E.g. when A submits IBs 1, 2 and 3 and then B submits IB 4 then 4 waits for 1,2,3, but 1,2,3 can run parallel to each other.
And yes adding anything as explicit sync would break that, but I don't think that this is much of a problem.
Regards, Christian.
--Jason
Regards, Christian.
dma_resv_unlock(dmabuf->resv);dma_fence_put(fence);return ret;+}
+static long dma_buf_signal_sync_file(struct dma_buf *dmabuf,
void __user *user_data)+{
struct dma_buf_sync_file arg;struct dma_fence *fence = NULL;struct sync_file *sync_file;int fd, ret;if (copy_from_user(&arg, user_data, sizeof(arg)))return -EFAULT;if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE)return -EINVAL;fd = get_unused_fd_flags(O_CLOEXEC);if (fd < 0)return fd;if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) {/* We need to include both the exclusive fence and all of* the shared fences in our fence.*/ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence);if (ret)goto err_put_fd;} else {fence = dma_resv_get_excl_rcu(dmabuf->resv);}if (!fence)fence = dma_fence_get_stub();sync_file = sync_file_create(fence);dma_fence_put(fence);if (!sync_file) {ret = -EINVAL;goto err_put_fd;}fd_install(fd, sync_file->file);arg.fd = fd;if (copy_to_user(user_data, &arg, sizeof(arg)))return -EFAULT;return 0;+err_put_fd:
put_unused_fd(fd);return ret;+}
- static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
@@ -390,6 +480,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
case DMA_BUF_IOCTL_WAIT_SYNC_FILE:return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg);case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE:return dma_buf_signal_sync_file(dmabuf, (void __user *)arg);default: return -ENOTTY; }diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..86e07acca90c 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file {
__u32 flags;__s32 fd;+};
+#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0)
- #define DMA_BUF_BASE 'b'
-#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on.
This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times.
There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages.
The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video.
v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence.
v3 (Jason Ekstrand): - Lock around setting shared fences as well as exclusive - Mark SIGNAL_SYNC_FILE as a read-write ioctl. - Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand): - Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand): - Rename the IOCTLs to import/export rather than wait/signal - Drop the WRITE flag and always get/set the exclusive fence
Signed-off-by: Jason Ekstrand jason@jlekstrand.net --- drivers/dma-buf/dma-buf.c | 84 ++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 11 ++++- 2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..d34d27aa3077 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,83 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; }
+static long dma_buf_import_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence, *singleton = NULL; + int ret = 0; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + dma_resv_lock(dmabuf->resv, NULL); + + ret = dma_resv_get_singleton(dmabuf->resv, fence, &singleton); + if (!ret && singleton) + dma_resv_add_excl_fence(dmabuf->resv, singleton); + + dma_resv_unlock(dmabuf->resv); + + dma_fence_put(fence); + + return ret; +} + +static long dma_buf_export_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence); + if (ret) + goto err_put_fd; + + if (!fence) + fence = dma_fence_get_stub(); + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +468,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg);
+ case DMA_BUF_IOCTL_IMPORT_SYNC_FILE: + return dma_buf_import_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_EXPORT_SYNC_FILE: + return dma_buf_export_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..b746c6459e24 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,15 @@ struct dma_buf_sync {
#define DMA_BUF_NAME_LEN 32
+struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 3, struct dma_buf_sync)
#endif
linaro-mm-sig@lists.linaro.org
-
Christian König -
Daniel Vetter -
Jason Ekstrand