Linaro-mm-sig February 2020

linaro-mm-sig@lists.linaro.org

10 participants
26 discussions

[PATCH 1/7] dma-buf: add dynamic DMA-buf handling v15

by Christian König

On the exporter side we add optional explicit pinning callbacks. Which are called when the importer doesn't implement dynamic handling, move notification or need the DMA-buf locked in place for its use case. On the importer side we add an optional move_notify callback. This callback is used by the exporter to inform the importers that their mappings should be destroyed as soon as possible. This allows the exporter to provide the mappings without the need to pin the backing store. v2: don't try to invalidate mappings when the callback is NULL, lock the reservation obj while using the attachments, add helper to set the callback v3: move flag for invalidation support into the DMA-buf, use new attach_info structure to set the callback v4: use importer_priv field instead of mangling exporter priv. v5: drop invalidation_supported flag v6: squash together with pin/unpin changes v7: pin/unpin takes an attachment now v8: nuke dma_buf_attachment_(map|unmap)_locked, everything is now handled backward compatible v9: always cache when export/importer don't agree on dynamic handling v10: minimal style cleanup v11: drop automatically re-entry avoidance v12: rename callback to move_notify v13: add might_lock in appropriate places v14: rebase on separated locking change v15: add EXPERIMENTAL flag, some more code comments Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/Kconfig | 10 ++ drivers/dma-buf/dma-buf.c | 110 ++++++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +- include/linux/dma-buf.h | 82 +++++++++++++-- 4 files changed, 188 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index e7d820ce0724..ef73b678419c 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -39,6 +39,16 @@ config UDMABUF A driver to let userspace turn memfd regions into dma-bufs. Qemu can use this to create host dmabufs for guest framebuffers. +config DMABUF_MOVE_NOTIFY + bool "Move notify between drivers (EXPERIMENTAL)" + default n + help + Don''t pin buffers if the dynamic DMA-buf interface is available on both the + exporter as well as the importer. This fixes a security problem where + userspace is able to pin unrestricted amounts of memory through DMA-buf. + But marked experimental because we don''t jet have a consistent execution + context and memory management between drivers. + config DMABUF_SELFTESTS tristate "Selftests for the dma-buf interfaces" default n diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..5f10d1929476 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -527,6 +527,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) exp_info->ops->dynamic_mapping)) return ERR_PTR(-EINVAL); + if (WARN_ON(!exp_info->ops->dynamic_mapping && + (exp_info->ops->pin || exp_info->ops->unpin))) + return ERR_PTR(-EINVAL); + if (!try_module_get(exp_info->owner)) return ERR_PTR(-ENOENT); @@ -651,7 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); * calls attach() of dma_buf_ops to allow device-specific attach functionality * @dmabuf: [in] buffer to attach device to. * @dev: [in] device to be attached. - * @dynamic_mapping: [in] calling convention for map/unmap + * @importer_ops [in] importer operations for the attachment + * @importer_priv [in] importer private pointer for the attachment * * Returns struct dma_buf_attachment pointer for this attachment. Attachments * must be cleaned up by calling dma_buf_detach(). @@ -667,11 +672,13 @@ EXPORT_SYMBOL_GPL(dma_buf_put); */ struct dma_buf_attachment * dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, - bool dynamic_mapping) + const struct dma_buf_attach_ops *importer_ops, + void *importer_priv) { struct dma_buf_attachment *attach; int ret; + /* TODO: make move_notify mandatory if importer_ops are provided. */ if (WARN_ON(!dmabuf || !dev)) return ERR_PTR(-EINVAL); @@ -681,7 +688,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, attach->dev = dev; attach->dmabuf = dmabuf; - attach->dynamic_mapping = dynamic_mapping; + attach->importer_ops = importer_ops; + attach->importer_priv = importer_priv; if (dmabuf->ops->attach) { ret = dmabuf->ops->attach(dmabuf, attach); @@ -700,15 +708,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, dma_buf_is_dynamic(dmabuf)) { struct sg_table *sgt; - if (dma_buf_is_dynamic(attach->dmabuf)) + if (dma_buf_is_dynamic(attach->dmabuf)) { dma_resv_lock(attach->dmabuf->resv, NULL); + ret = dma_buf_pin(attach); + if (ret) + goto err_unlock; + } sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); if (!sgt) sgt = ERR_PTR(-ENOMEM); if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); - goto err_unlock; + goto err_unpin; } if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); @@ -722,6 +734,10 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, kfree(attach); return ERR_PTR(ret); +err_unpin: + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_buf_unpin(attach); + err_unlock: if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); @@ -742,7 +758,7 @@ EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach); struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev) { - return dma_buf_dynamic_attach(dmabuf, dev, false); + return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL); } EXPORT_SYMBOL_GPL(dma_buf_attach); @@ -765,8 +781,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); - if (dma_buf_is_dynamic(attach->dmabuf)) + if (dma_buf_is_dynamic(attach->dmabuf)) { + dma_buf_unpin(attach); dma_resv_unlock(attach->dmabuf->resv); + } } dma_resv_lock(dmabuf->resv, NULL); @@ -779,6 +797,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) } EXPORT_SYMBOL_GPL(dma_buf_detach); +/** + * dma_buf_pin - Lock down the DMA-buf + * + * @attach: [in] attachment which should be pinned + * + * Returns: + * 0 on success, negative error code on failure. + */ +int dma_buf_pin(struct dma_buf_attachment *attach) +{ + struct dma_buf *dmabuf = attach->dmabuf; + int ret = 0; + + dma_resv_assert_held(dmabuf->resv); + + if (dmabuf->ops->pin) + ret = dmabuf->ops->pin(attach); + + return ret; +} +EXPORT_SYMBOL_GPL(dma_buf_pin); + +/** + * dma_buf_unpin - Remove lock from DMA-buf + * + * @attach: [in] attachment which should be unpinned + */ +void dma_buf_unpin(struct dma_buf_attachment *attach) +{ + struct dma_buf *dmabuf = attach->dmabuf; + + dma_resv_assert_held(dmabuf->resv); + + if (dmabuf->ops->unpin) + dmabuf->ops->unpin(attach); +} +EXPORT_SYMBOL_GPL(dma_buf_unpin); + /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the @@ -798,6 +854,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, enum dma_data_direction direction) { struct sg_table *sg_table; + int r; might_sleep(); @@ -819,13 +876,25 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return attach->sgt; } - if (dma_buf_is_dynamic(attach->dmabuf)) + if (dma_buf_is_dynamic(attach->dmabuf)) { dma_resv_assert_held(attach->dmabuf->resv); + if (!attach->importer_ops->move_notify || + !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) { + r = dma_buf_pin(attach); + if (r) + return ERR_PTR(r); + } + } sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); + if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) && + (!attach->importer_ops->move_notify || + !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))) + dma_buf_unpin(attach); + if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) { attach->sgt = sg_table; attach->dir = direction; @@ -864,9 +933,34 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, dma_resv_assert_held(attach->dmabuf->resv); attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); + + if (dma_buf_is_dynamic(attach->dmabuf) && + (!attach->importer_ops->move_notify || + !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))) + dma_buf_unpin(attach); } EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +/** + * dma_buf_move_notify - notify attachments that DMA-buf is moving + * + * @dmabuf: [in] buffer which is moving + * + * Informs all attachmenst that they need to destroy and recreated all their + * mappings. + */ +void dma_buf_move_notify(struct dma_buf *dmabuf) +{ + struct dma_buf_attachment *attach; + + dma_resv_assert_held(dmabuf->resv); + + list_for_each_entry(attach, &dmabuf->attachments, node) + if (attach->importer_ops && attach->importer_ops->move_notify) + attach->importer_ops->move_notify(attach); +} +EXPORT_SYMBOL_GPL(dma_buf_move_notify); + /** * DOC: cpu access * diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index a59cd47aa6c1..7cafc65fd76a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -412,6 +412,9 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf) return ERR_PTR(ret); } +static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = { +}; + /** * amdgpu_gem_prime_import - &drm_driver.gem_prime_import implementation * @dev: DRM device @@ -444,7 +447,8 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev, if (IS_ERR(obj)) return obj; - attach = dma_buf_dynamic_attach(dma_buf, dev->dev, true); + attach = dma_buf_dynamic_attach(dma_buf, dev->dev, + &amdgpu_dma_buf_attach_ops, NULL); if (IS_ERR(attach)) { drm_gem_object_put(obj); return ERR_CAST(attach); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index abf5459a5b9d..b38cea240b67 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -93,14 +93,41 @@ struct dma_buf_ops { */ void (*detach)(struct dma_buf *, struct dma_buf_attachment *); + /** + * @pin: + * + * This is called by dma_buf_pin and lets the exporter know that the + * DMA-buf can't be moved any more. + * + * This is called with the dmabuf->resv object locked. + * + * This callback is optional and should only be used in limited use + * cases like scanout and not for temporary pin operations. + * + * Returns: + * + * 0 on success, negative error code on failure. + */ + int (*pin)(struct dma_buf_attachment *attach); + + /** + * @unpin: + * + * This is called by dma_buf_unpin and lets the exporter know that the + * DMA-buf can be moved again. + * + * This is called with the dmabuf->resv object locked. + * + * This callback is optional. + */ + void (*unpin)(struct dma_buf_attachment *attach); + /** * @map_dma_buf: * * This is called by dma_buf_map_attachment() and is used to map a * shared &dma_buf into device address space, and it is mandatory. It - * can only be called if @attach has been called successfully. This - * essentially pins the DMA buffer into place, and it cannot be moved - * any more + * can only be called if @attach has been called successfully. * * This call may sleep, e.g. when the backing storage first needs to be * allocated, or moved to a location suitable for all currently attached @@ -141,9 +168,8 @@ struct dma_buf_ops { * * This is called by dma_buf_unmap_attachment() and should unmap and * release the &sg_table allocated in @map_dma_buf, and it is mandatory. - * It should also unpin the backing storage if this is the last mapping - * of the DMA buffer, it the exporter supports backing storage - * migration. + * For static dma_buf handling this might also unpins the backing + * storage if this is the last mapping of the DMA buffer. */ void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *, @@ -311,6 +337,34 @@ struct dma_buf { } cb_excl, cb_shared; }; +/** + * struct dma_buf_attach_ops - importer operations for an attachment + * @move_notify: [optional] notification that the DMA-buf is moving + * + * Attachment operations implemented by the importer. + */ +struct dma_buf_attach_ops { + /** + * @move_notify + * + * If this callback is provided the framework can avoid pinning the + * backing store while mappings exists. + * + * This callback is called with the lock of the reservation object + * associated with the dma_buf held and the mapping function must be + * called with this lock held as well. This makes sure that no mapping + * is created concurrently with an ongoing move operation. + * + * Mappings stay valid and are not directly affected by this callback. + * But the DMA-buf can now be in a different physical location, so all + * mappings should be destroyed and re-created as soon as possible. + * + * New mappings can be created after this callback returns, and will + * point to the new location of the DMA-buf. + */ + void (*move_notify)(struct dma_buf_attachment *attach); +}; + /** * struct dma_buf_attachment - holds device-buffer attachment data * @dmabuf: buffer for this attachment. @@ -319,8 +373,9 @@ struct dma_buf { * @sgt: cached mapping. * @dir: direction of cached mapping. * @priv: exporter specific attachment data. - * @dynamic_mapping: true if dma_buf_map/unmap_attachment() is called with the - * dma_resv lock held. + * @importer_ops: importer operations for this attachment, if provided + * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held. + * @importer_priv: importer specific attachment data. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -337,7 +392,8 @@ struct dma_buf_attachment { struct list_head node; struct sg_table *sgt; enum dma_data_direction dir; - bool dynamic_mapping; + const struct dma_buf_attach_ops *importer_ops; + void *importer_priv; void *priv; }; @@ -399,6 +455,7 @@ static inline void get_dma_buf(struct dma_buf *dmabuf) */ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) { + /* TODO: switch to using pin/unpin functions as indicator. */ return dmabuf->ops->dynamic_mapping; } @@ -413,16 +470,19 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) static inline bool dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach) { - return attach->dynamic_mapping; + return !!attach->importer_ops; } struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); struct dma_buf_attachment * dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, - bool dynamic_mapping); + const struct dma_buf_attach_ops *importer_ops, + void *importer_priv); void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach); +int dma_buf_pin(struct dma_buf_attachment *attach); +void dma_buf_unpin(struct dma_buf_attachment *attach); struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info); -- 2.17.1

4 years

[PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

by 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(a)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 -- 2.24.1

4 years, 1 month

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

by Christian König

Am 26.02.20 um 17:46 schrieb Bas Nieuwenhuizen: > On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand <jason(a)jlekstrand.net> wrote: >> On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter <daniel(a)ffwll.ch> wrote: >>> On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote: >>> [SNIP] >>>> 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. First of all you need to grab the lock of the dma_resv object or you can't replace the exclusive nor the shared ones. This way you don't need to do a atomic_cmpxchg or anything else and still guarantee correct ordering. > I think for an exclusive fence you may need to create a fence array > that includes the existing exclusive and shared fences in the dma_resv > combined with the added fence. Yes, that at least gives us the correct synchronization. > However, I'm not sure what the best way is to do garbage collection on > that so that we don't get an impossibly list of fence arrays. Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection. When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused. > (Note > the dma_resv has a lock that needs to be taken before adding an > exclusive fence, might be useful). Some code that does a thing like > this is __dma_resv_make_exclusive in > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this. Regards, Christian. > The other piece of the puzzle is that on the submit path this would > need something to ignore implicit fences. And there semantically the > question comes up whether it is safe for a driver to ignore exclusive > fences from another driver. (and then we have amdgpu which has its own > rules on exclusiveness of its shared fences based on the context. e.g. > the current option to ignore implicit fences for a buffer still syncs > on exclusive fences on the buffer).

4 years, 1 month

Re: [Linaro-mm-sig] [PATCH] dma-buf: free dmabuf->name in dma_buf_release()

by Andrew Morton

On Thu, 27 Feb 2020 13:38:03 -0800 Cong Wang <xiyou.wangcong(a)gmail.com> wrote: > On Tue, Feb 25, 2020 at 5:54 PM Andrew Morton <akpm(a)linux-foundation.org> wrote: > > > > On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang <xiyou.wangcong(a)gmail.com> wrote: > > > > > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set > > > it never gets freed. > > > > > > Free it in dma_buf_release(). > > > > > > ... > > > > > > --- a/drivers/dma-buf/dma-buf.c > > > +++ b/drivers/dma-buf/dma-buf.c > > > @@ -108,6 +108,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) > > > dma_resv_fini(dmabuf->resv); > > > > > > module_put(dmabuf->owner); > > > + kfree(dmabuf->name); > > > kfree(dmabuf); > > > return 0; > > > } > > > > ow. Is that ioctl privileged? > > It looks unprivileged to me, as I don't see capable() called along > the path. > OK, thanks. I added cc:stable to my copy.

4 years, 1 month

Re: [Linaro-mm-sig] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2

by Christian König

Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware): > On 2/23/20 4:45 PM, Christian König wrote: >> Am 21.02.20 um 18:12 schrieb Daniel Vetter: >>> [SNIP] >>> Yeah the Great Plan (tm) is to fully rely on ww_mutex slowly >>> degenerating >>> into essentially a global lock. But only when there's actual contention >>> and thrashing. >> >> Yes exactly. A really big problem in TTM is currently that we drop >> the lock after evicting BOs because they tend to move in again >> directly after that. >> >> From practice I can also confirm that there is exactly zero benefit >> from dropping locks early and reacquire them for example for the VM >> page tables. That's just makes it more likely that somebody needs to >> roll back and this is what we need to avoid in the first place. > > If you have a benchmarking setup available it would be very > interesting for future reference to see how changing from WD to WW > mutexes affects the roll back frequency. WW is known to cause > rollbacks much less frequently but there is more work associated with > each rollback. Not of hand. To be honest I still have a hard time to get a grip on the difference between WD and WW from the algorithm point of view. So I can't judge that difference at all. >> Contention on BO locks during command submission is perfectly fine as >> long as this is as lightweight as possible while we don't have >> trashing. When we have trashing multi submission performance is best >> archived to just favor a single process to finish its business and >> block everybody else. > > Hmm. Sounds like we need a per-manager ww_rwsem protecting manager > allocation, taken in write-mode then there's thrashing. In read-mode > otherwise. That would limit the amount of "unnecessary" locks we'd > have to keep and reduce unwanted side-effects, (see below): Well per-manager (you mean per domain here don't you?) doesn't sound like that useful because we rarely use only one domain, but I'm actually questioning for quite a while if the per BO lock scheme was the right approach. See from the performance aspect the closest to ideal solution I can think of would be a ww_rwsem per user of a resource. In other words we don't lock BOs, but instead a list of all their users and when you want to evict a BO you need to walk that list and inform all users that the BO will be moving. During command submission you then have the fast path which rather just grabs the read side of the user lock and check if all BOs are still in the expected place. If some BOs were evicted you back off and start the slow path, e.g. maybe even copy additional data from userspace then grab the write side of the lock etc.. etc... That approach is similar to what we use in amdgpu with the per-VM BOs, but goes a step further. Problem is that we are so used to per BO locks in the kernel that this is probably not doable any more. >> Because of this I would actually vote for forbidding to release >> individual ww_mutex() locks in a context. > > Yes, I see the problem. > > But my first reaction is that this might have undersirable > side-effects. Let's say somebody wanted to swap the evicted BOs out? Please explain further, I off hand don't see the problem here. In general I actually wanted to re-work TTM in a way that BOs in the SYSTEM/SWAPABLE domain are always backed by a shmem file instead of the struct page array we currently have. > Or cpu-writes to them causing faults, that might also block the > mm_sem, which in turn blocks hugepaged? Mhm, I also only have a higher level view how hugepaged works so why does it grabs the mm_sem on the write side? Thanks, Christian. > > Still it's a fairly simple solution to a problem that seems otherwise > hard to solve efficiently. > > Thanks, > Thomas > > >> >> Regards, >> Christian. >> >>> -Daniel > >

4 years, 1 month

Re: [Linaro-mm-sig] [virtio-dev] Re: [PATCH 1/2] virtio: add dma-buf support for exported objects

by Gerd Hoffmann

On Wed, Feb 26, 2020 at 12:56:58PM +0900, David Stevens wrote: > On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > > > How about dma_buf_{get,set}_uuid, simliar to dma_buf_set_name? > > While I'm not opposed to such an API, I'm also hesitant to make > changes to the dma-buf API for a single use case. See virtio-wayland discussion. I expect we will see more cases show up. Maybe this should even go one level up, to struct file. cheers, Gerd

4 years, 1 month

[PATCH v5 3/3] drm/udl: simplify gem object mapping.

by Gerd Hoffmann

With shmem helpers allowing to update pgprot caching flags via drm_gem_shmem_object.map_cached we can just use that and ditch our own implementations of mmap() and vmap(). We also don't need a special case for imported objects, any map requests are handled by the exporter not udl. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- drivers/gpu/drm/udl/udl_gem.c | 62 ++--------------------------------- 1 file changed, 3 insertions(+), 59 deletions(-) diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c index b6e26f98aa0a..7e3a88b25b6b 100644 --- a/drivers/gpu/drm/udl/udl_gem.c +++ b/drivers/gpu/drm/udl/udl_gem.c @@ -17,72 +17,15 @@ * GEM object funcs */ -static int udl_gem_object_mmap(struct drm_gem_object *obj, - struct vm_area_struct *vma) -{ - int ret; - - ret = drm_gem_shmem_mmap(obj, vma); - if (ret) - return ret; - - vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); - if (obj->import_attach) - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot); - vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); - - return 0; -} - -static void *udl_gem_object_vmap(struct drm_gem_object *obj) -{ - struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); - int ret; - - ret = mutex_lock_interruptible(&shmem->vmap_lock); - if (ret) - return ERR_PTR(ret); - - if (shmem->vmap_use_count++ > 0) - goto out; - - ret = drm_gem_shmem_get_pages(shmem); - if (ret) - goto err_zero_use; - - if (obj->import_attach) - shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf); - else - shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT, - VM_MAP, PAGE_KERNEL); - - if (!shmem->vaddr) { - DRM_DEBUG_KMS("Failed to vmap pages\n"); - ret = -ENOMEM; - goto err_put_pages; - } - -out: - mutex_unlock(&shmem->vmap_lock); - return shmem->vaddr; - -err_put_pages: - drm_gem_shmem_put_pages(shmem); -err_zero_use: - shmem->vmap_use_count = 0; - mutex_unlock(&shmem->vmap_lock); - return ERR_PTR(ret); -} - static const struct drm_gem_object_funcs udl_gem_object_funcs = { .free = drm_gem_shmem_free_object, .print_info = drm_gem_shmem_print_info, .pin = drm_gem_shmem_pin, .unpin = drm_gem_shmem_unpin, .get_sg_table = drm_gem_shmem_get_sg_table, - .vmap = udl_gem_object_vmap, + .vmap = drm_gem_shmem_vmap, .vunmap = drm_gem_shmem_vunmap, - .mmap = udl_gem_object_mmap, + .mmap = drm_gem_shmem_mmap, }; /* @@ -101,6 +44,7 @@ struct drm_gem_object *udl_driver_gem_create_object(struct drm_device *dev, obj = &shmem->base; obj->funcs = &udl_gem_object_funcs; + shmem->map_cached = true; return obj; } -- 2.18.2

4 years, 1 month

Re: [Linaro-mm-sig] [PATCH] dma-buf: free dmabuf->name in dma_buf_release()

by Andrew Morton

On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang <xiyou.wangcong(a)gmail.com> wrote: > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set > it never gets freed. > > Free it in dma_buf_release(). > > ... > > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -108,6 +108,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) > dma_resv_fini(dmabuf->resv); > > module_put(dmabuf->owner); > + kfree(dmabuf->name); > kfree(dmabuf); > return 0; > } ow. Is that ioctl privileged?

4 years, 1 month

Re: [Linaro-mm-sig] [PATCH] dma-buf: Fix missing excl fence waiting

by Christian König

Am 23.02.20 um 12:56 schrieb Pan, Xinhui: > If shared fence list is not empty, even we want to test all fences, excl fence is ignored. > That is abviously wrong, so fix it. Yeah that is a known issue and I completely agree with you, but other disagree. See the shared fences are meant to depend on the exclusive fence. So all shared fences must finish only after the exclusive one has finished as well. The problem now is that for error handling this isn't necessary true. In other words when a shared fence completes with an error it is perfectly possible that he does this before the exclusive fence is finished. I'm trying to convince Daniel that this is a problem for years :) Regards, Christian. > > Signed-off-by: xinhui pan <xinhui.pan(a)amd.com> > --- > drivers/dma-buf/dma-resv.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > index 4264e64788c4..44dc64c547c6 100644 > --- a/drivers/dma-buf/dma-resv.c > +++ b/drivers/dma-buf/dma-resv.c > @@ -632,14 +632,14 @@ static inline int dma_resv_test_signaled_single(struct dma_fence *passed_fence) > */ > bool dma_resv_test_signaled_rcu(struct dma_resv *obj, bool test_all) > { > - unsigned seq, shared_count; > + unsigned int seq, shared_count, left; > int ret; > > rcu_read_lock(); > retry: > ret = true; > shared_count = 0; > - seq = read_seqcount_begin(&obj->seq); > + left = seq = read_seqcount_begin(&obj->seq); > > if (test_all) { > unsigned i; > @@ -647,7 +647,7 @@ bool dma_resv_test_signaled_rcu(struct dma_resv *obj, bool test_all) > struct dma_resv_list *fobj = rcu_dereference(obj->fence); > > if (fobj) > - shared_count = fobj->shared_count; > + left = shared_count = fobj->shared_count; > > for (i = 0; i < shared_count; ++i) { > struct dma_fence *fence = rcu_dereference(fobj->shared[i]); > @@ -657,13 +657,14 @@ bool dma_resv_test_signaled_rcu(struct dma_resv *obj, bool test_all) > goto retry; > else if (!ret) > break; > + left--; > } > > if (read_seqcount_retry(&obj->seq, seq)) > goto retry; > } > > - if (!shared_count) { > + if (!left) { > struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl); > > if (fence_excl) {

4 years, 1 month

Re: [Linaro-mm-sig] [PATCH 2/2] drm/virtio: Support virtgpu exported resources

by Gerd Hoffmann

Hi, > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags) > +{ [ ... ] > +} > + > +struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev, > + struct dma_buf *buf) > +{ [ ... ] > +} More code duplication. > diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h > index 0c85914d9369..9c428ef03060 100644 > --- a/include/uapi/linux/virtio_gpu.h > +++ b/include/uapi/linux/virtio_gpu.h API change should go to a separate patch. > +/* > + * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID > + */ > +#define VIRTIO_GPU_F_CROSS_DEVICE 2 Hmm, how about VIRTIO_GPU_F_RESOURCE_UUID ? > @@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type { > VIRTIO_GPU_RESP_OK_CAPSET_INFO, > VIRTIO_GPU_RESP_OK_CAPSET, > VIRTIO_GPU_RESP_OK_EDID, > + VIRTIO_GPU_RESP_OK_RESOURCE_ASSIGN_UUID, The "assign" doesn't make sense in the reply. I'd name that VIRTIO_GPU_RESP_OK_RESOURCE_UUID or just VIRTIO_GPU_RESP_OK_UUID, > +/* VIRTIO_GPU_RESP_OK_RESOURCE_ASSIGN_UUID */ > +struct virtio_gpu_resp_resource_assign_uuid { > + struct virtio_gpu_ctrl_hdr hdr; > + __u8 uuid[16]; > +}; Same here. cheers, Gerd

4 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig February 2020