- Linaro-mm-sig - lists.linaro.org

Re: [Linaro-mm-sig] [PATCH] dma-buf: Update docs for SYNC ioctl

by David Herrmann

Hi On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti <tiago.vignatti(a)intel.com> wrote: > Do we have an agreement here after all? David? I need to know whether this > fixup is okay to go cause I'll need to submit to Chrome OS then. Sure it is fine. The code is already there, we cannot change it. Thanks David

9 years, 2 months

1
0
0 0

[PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

by Chris Wilson

Drivers, especially i915.ko, can fail during the initial migration of a dma-buf for CPU access. However, the error code from the driver was not being propagated back to ioctl and so userspace was blissfully ignorant of the failure. Rendering corruption ensues. Whilst fixing the ioctl to return the error code from dma_buf_start_cpu_access(), also do the same for dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access() cannot fail. i915.ko however, as most drivers would, wants to avoid being uninterruptible (as would be required to guarrantee no failure when flushing the buffer to the device). As userspace already has to handle errors from the SYNC_IOCTL, take advantage of this to be able to restart the syscall across signals. This fixes a coherency issue for i915.ko as well as reducing the uninterruptible hold upon its BKL, the struct_mutex. Fixes commit c11e391da2a8fe973c3c2398452000bed505851e Author: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Thu Feb 11 20:04:51 2016 -0200 dma-buf: Add ioctls to allow userspace to flush Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible Testcase: igt/prime_mmap_coherency/ioctl-errors Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tiago Vignatti <tiago.vignatti(a)intel.com> Cc: Stéphane Marchesin <marcheu(a)chromium.org> Cc: David Herrmann <dh.herrmann(a)gmail.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Daniel Vetter <daniel.vetter(a)intel.com> CC: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: intel-gfx(a)lists.freedesktop.org Cc: devel(a)driverdev.osuosl.org --- drivers/dma-buf/dma-buf.c | 17 +++++++++++------ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 15 +++++---------- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++-- drivers/gpu/drm/udl/udl_fb.c | 4 ++-- drivers/staging/android/ion/ion.c | 6 ++++-- include/linux/dma-buf.h | 6 +++--- 6 files changed, 28 insertions(+), 25 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 9810d1df0691..774a60f4309a 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file, struct dma_buf *dmabuf; struct dma_buf_sync sync; enum dma_data_direction direction; + int ret; dmabuf = file->private_data; @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file, } if (sync.flags & DMA_BUF_SYNC_END) - dma_buf_end_cpu_access(dmabuf, direction); + ret = dma_buf_end_cpu_access(dmabuf, direction); else - dma_buf_begin_cpu_access(dmabuf, direction); + ret = dma_buf_begin_cpu_access(dmabuf, direction); - return 0; + return ret; default: return -ENOTTY; } @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); * * This call must always succeed. */ -void dma_buf_end_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) +int dma_buf_end_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) { + int ret = 0; + WARN_ON(!dmabuf); if (dmabuf->ops->end_cpu_access) - dmabuf->ops->end_cpu_access(dmabuf, direction); + ret = dmabuf->ops->end_cpu_access(dmabuf, direction); + + return ret; } EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index 1f3eef6fb345..0506016e18e0 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, enum dma_data_dire return ret; } -static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction direction) +static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction direction) { struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf); struct drm_device *dev = obj->base.dev; - struct drm_i915_private *dev_priv = to_i915(dev); - bool was_interruptible; int ret; - mutex_lock(&dev->struct_mutex); - was_interruptible = dev_priv->mm.interruptible; - dev_priv->mm.interruptible = false; + ret = i915_mutex_lock_interruptible(dev); + if (ret) + return ret; ret = i915_gem_object_set_to_gtt_domain(obj, false); - - dev_priv->mm.interruptible = was_interruptible; mutex_unlock(&dev->struct_mutex); - if (unlikely(ret)) - DRM_ERROR("unable to flush buffer following CPU access; rendering may be corrupt\n"); + return ret; } static const struct dma_buf_ops i915_dmabuf_ops = { diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c index 3cf8aab23a39..af267c35d813 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c @@ -97,11 +97,12 @@ static int omap_gem_dmabuf_begin_cpu_access(struct dma_buf *buffer, return omap_gem_get_pages(obj, &pages, true); } -static void omap_gem_dmabuf_end_cpu_access(struct dma_buf *buffer, - enum dma_data_direction dir) +static int omap_gem_dmabuf_end_cpu_access(struct dma_buf *buffer, + enum dma_data_direction dir) { struct drm_gem_object *obj = buffer->priv; omap_gem_put_pages(obj); + return 0; } diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c index c427499133d6..33239a2b264a 100644 --- a/drivers/gpu/drm/udl/udl_fb.c +++ b/drivers/gpu/drm/udl/udl_fb.c @@ -423,8 +423,8 @@ static int udl_user_framebuffer_dirty(struct drm_framebuffer *fb, } if (ufb->obj->base.import_attach) { - dma_buf_end_cpu_access(ufb->obj->base.import_attach->dmabuf, - DMA_FROM_DEVICE); + ret = dma_buf_end_cpu_access(ufb->obj->base.import_attach->dmabuf, + DMA_FROM_DEVICE); } unlock: diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 0754a37c9674..49436b4510f4 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1075,14 +1075,16 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, return PTR_ERR_OR_ZERO(vaddr); } -static void ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) +static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf, + enum dma_data_direction direction) { struct ion_buffer *buffer = dmabuf->priv; mutex_lock(&buffer->lock); ion_buffer_kmap_put(buffer); mutex_unlock(&buffer->lock); + + return 0; } static struct dma_buf_ops dma_buf_ops = { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 532108ea0c1c..3fe90d494edb 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -94,7 +94,7 @@ struct dma_buf_ops { void (*release)(struct dma_buf *); int (*begin_cpu_access)(struct dma_buf *, enum dma_data_direction); - void (*end_cpu_access)(struct dma_buf *, enum dma_data_direction); + int (*end_cpu_access)(struct dma_buf *, enum dma_data_direction); void *(*kmap_atomic)(struct dma_buf *, unsigned long); void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *); void *(*kmap)(struct dma_buf *, unsigned long); @@ -224,8 +224,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, enum dma_data_direction); int dma_buf_begin_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction dir); -void dma_buf_end_cpu_access(struct dma_buf *dma_buf, - enum dma_data_direction dir); +int dma_buf_end_cpu_access(struct dma_buf *dma_buf, + enum dma_data_direction dir); void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); void *dma_buf_kmap(struct dma_buf *, unsigned long); -- 2.8.0.rc3

9 years, 2 months

6
14
0 0

Re: [Linaro-mm-sig] [PATCH] fence: add missing descriptions for fence

by Javier Martinez Canillas

Hello Luis, On Sat, Mar 19, 2016 at 4:50 PM, Luis de Bethencourt <luisbg(a)osg.samsung.com> wrote: > Commit b55b54b5db33 ("staging/android: remove struct sync_pt") > added the members child_list and active_list to the fence struct, but > didn't add descriptions for these. Adding the descriptions. > Patches whose commit message mentions a specific commit that introduced and issue, usually also have a "Fixes:" tag before the S-o-B. For example this patch should have: Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt") > Signed-off-by: Luis de Bethencourt <luisbg(a)osg.samsung.com> > --- > Hi, > > Noticed this missing descriptions when running make htmldocs. > > Got the following warnings: > .//include/linux/fence.h:84: warning: No description found for parameter 'child_list' > .//include/linux/fence.h:84: warning: No description found for parameter 'active_list' > > Thanks :) > Luis > Patch looks good to me. Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Best regards, Javier

9 years, 2 months

1
0
0 0

[PATCH] dma-buf/fence: fix fence_is_later v2

by Alex Deucher

From: Christian König <christian.koenig(a)amd.com> A fence is never later than itself. This caused a bunch of overhead for AMDGPU. v2: simplify check as suggested by Michel. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- include/linux/fence.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index bb52201..5aa95eb 100644 --- a/include/linux/fence.h +++ b/include/linux/fence.h @@ -292,7 +292,7 @@ static inline bool fence_is_later(struct fence *f1, struct fence *f2) if (WARN_ON(f1->context != f2->context)) return false; - return f1->seqno - f2->seqno < INT_MAX; + return (int)(f1->seqno - f2->seqno) > 0; } /** -- 2.5.0

9 years, 3 months

5
4
0 0

[PATCH 0/2] iommu: fix handling of attach/detach for default domains

by Marek Szyprowski

Hello, This patchset fixes attaching and detaching devices to a group, which has default domain configured. With both patches applied all calls to iommu's attach/detach functions will be balanced, whenever caller attaches device to the default domain or the custom one. Best regards Marek Szyprowski Samsung R&D Institute Poland Patch summary: Marek Szyprowski (2): iommu: call detach also for default_domain before attaching to new one iommu: fix default domain handling in __iommu_detach_group() drivers/iommu/iommu.c | 48 +++++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 21 deletions(-) -- 1.9.2

9 years, 3 months

2
7
0 0

[PATCH] dma-buf/fence: fix fence_is_later v2

by Alex Deucher

From: Christian König <christian.koenig(a)amd.com> A fence is never later than itself. This caused a bunch of overhead for AMDGPU. v2: simplify check as suggested by Michel. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- include/linux/fence.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index bb52201..5aa95eb 100644 --- a/include/linux/fence.h +++ b/include/linux/fence.h @@ -292,7 +292,7 @@ static inline bool fence_is_later(struct fence *f1, struct fence *f2) if (WARN_ON(f1->context != f2->context)) return false; - return f1->seqno - f2->seqno < INT_MAX; + return (int)(f1->seqno - f2->seqno) > 0; } /** -- 2.5.0

9 years, 3 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v5 0/3] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

2015-10-21 16:34 GMT+02:00 James Morris <jmorris(a)namei.org>: > On Wed, 21 Oct 2015, Benjamin Gaignard wrote: > >> >> The outcome of the previous RFC about how do secure data path was the need >> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) >> > > Have you addressed all the questions raised by Alan here: > > https://lkml.org/lkml/2015/5/8/629 SMAF create /dev/smaf where all allocations could be done and is the owner of the dmabuf. Secure module is called to check permissions before that the CPU could access to the memory. I hope this cover what Alan expected but I can't speak form him. > > Also, is there any application of this beyond DRM? > If you don't use the secure part you can consider that SMAF is a central allocator with helpers to select the best allocator for your hardware devices. While SMAF doesn't rely on DRM concepts (crypto, CENC, keys etc...) we can use it outside this context but obviously it that been first designed for DRM uses cases. > > - James > -- > James Morris > <jmorris(a)namei.org> > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

9 years, 7 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v5 1/3] create SMAF module

by Benjamin Gaignard

2015-10-21 16:32 GMT+02:00 James Morris <jmorris(a)namei.org>: > On Wed, 21 Oct 2015, Benjamin Gaignard wrote: > >> Secure Memory Allocation Framework goal is to be able >> to allocate memory that can be securing. >> There is so much ways to allocate and securing memory that SMAF >> doesn't do it by itself but need help of additional modules. >> To be sure to use the correct allocation method SMAF implement >> deferred allocation (i.e. allocate memory when only really needed) >> >> Allocation modules (smaf-alloctor.h): >> SMAF could manage with multiple allocation modules at same time. >> To select the good one SMAF call match() to be sure that a module >> can allocate memory for a given list of devices. It is to the module >> to check if the devices are compatible or not with it allocation >> method. >> >> Securing module (smaf-secure.h): >> The way of how securing memory it is done is platform specific. >> Secure module is responsible of grant/revoke memory access. >> > > This documentation is highly inadequate. If you give hints I will try to complete it and make it acceptable. > > What does "allocate memory that can be securing" mean? Maybe I could re-phrase it like that: "Secure Memory Allocation Framework goal is to be able to allocate memory that the platform can secure." I'm trying to be generic here because each could have it own method to secure buffers. > > > -- > James Morris > <jmorris(a)namei.org> > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

9 years, 7 months

1
0
0 0

[PATCH v5 0/3] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

version 5 changes: - rebased on kernel 4.3-rc6 - rework locking schema and make handle status use an atomic_t - add a fake secure module to allow performing tests without trusted environment version 4 changes: - rebased on kernel 4.3-rc3 - fix missing EXPORT_SYMBOL for smaf_create_handle() version 3 changes: - Remove ioctl for allocator selection instead provide the name of the targeted allocator with allocation request. Selecting allocator from userland isn't the prefered way of working but is needed when the first user of the buffer is a software component. - Fix issues in case of error while creating smaf handle. - Fix module license. - Update libsmaf and tests to care of the SMAF API evolution https://git.linaro.org/people/benjamin.gaignard/libsmaf.git version 2 changes: - Add one ioctl to allow allocator selection from userspace. This is required for the uses case where the first user of the buffer is a software IP which can't perform dma_buf attachement. - Add name and ranking to allocator structure to be able to sort them. - Create a tiny library to test SMAF: https://git.linaro.org/people/benjamin.gaignard/libsmaf.git - Fix one issue when try to secure buffer without secure module registered The outcome of the previous RFC about how do secure data path was the need of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) SMAF goal is to provide a framework that allow allocating and securing memory by using dma_buf. Each platform have it own way to perform those two features so SMAF design allow to register helper modules to perform them. To be sure to select the best allocation method for devices SMAF implement deferred allocation mechanism: memory allocation is only done when the first device effectively required it. Allocator modules have to implement a match() to let SMAF know if they are compatibles with devices needs. This patch set provide an example of allocator module which use dma_{alloc/free/mmap}_attrs() and check if at least one device have coherent_dma_mask set to DMA_BIT_MASK(32) in match function. I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if a better name could be found for this file. Secure modules are responsibles of granting and revoking devices access rights on the memory. Secure module is also called to check if CPU map memory into kernel and user address spaces. An example of secure module implementation can be found here: http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git This code isn't yet part of the patch set because it depends on generic TEE which is still under discussion (https://lwn.net/Articles/644646/) For allocation part of SMAF code I get inspirated by Sumit Semwal work about constraint aware allocator. Benjamin Gaignard (3): create SMAF module SMAF: add CMA allocator SMAF: add fake secure module drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 17 + drivers/smaf/Makefile | 3 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 753 +++++++++++++++++++++++++++++++++++++++++ drivers/smaf/smaf-fakesecure.c | 92 +++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 75 ++++ include/uapi/linux/smaf.h | 52 +++ 10 files changed, 1249 insertions(+) create mode 100644 drivers/smaf/Kconfig create mode 100644 drivers/smaf/Makefile create mode 100644 drivers/smaf/smaf-cma.c create mode 100644 drivers/smaf/smaf-core.c create mode 100644 drivers/smaf/smaf-fakesecure.c create mode 100644 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

9 years, 7 months

1
3
0 0

Re: [Linaro-mm-sig] [PATCH v4 1/2] create SMAF module

by Benjamin Gaignard

Thanks for your review I will add a lock in smaf_handle structure. One of the goal of smaf is to create a standard kernel API to allocate and secure buffers to avoid forking while implementing buffer securing feature. One concern about ION is that the selection of the heap is done by userland so hardware constraints need to be known by the userland, which is problematic from my point of view. Compare to ION I have try to introduce features like securing API, flexible allocator selection on kernel and the possibility to add custom allocator and securing modules. Benjamin 2015-10-06 3:58 GMT+02:00 Laura Abbott <labbott(a)redhat.com>: > On 10/05/2015 03:11 AM, Benjamin Gaignard wrote: >> >> diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c >> new file mode 100644 >> index 0000000..37914e7 >> --- /dev/null >> +++ b/drivers/smaf/smaf-core.c >> @@ -0,0 +1,736 @@ >> +/* >> + * smaf.c >> + * >> + * Copyright (C) Linaro SA 2015 >> + * Author: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> for Linaro. >> + * License terms: GNU General Public License (GPL), version 2 >> + */ >> + >> +#include <linux/device.h> >> +#include <linux/dma-buf.h> >> +#include <linux/dma-mapping.h> >> +#include <linux/fs.h> >> +#include <linux/ioctl.h> >> +#include <linux/list_sort.h> >> +#include <linux/miscdevice.h> >> +#include <linux/module.h> >> +#include <linux/slab.h> >> +#include <linux/smaf.h> >> +#include <linux/smaf-allocator.h> >> +#include <linux/smaf-secure.h> >> +#include <linux/uaccess.h> >> + >> +struct smaf_handle { >> + struct dma_buf *dmabuf; >> + struct smaf_allocator *allocator; >> + struct dma_buf *db_alloc; >> + size_t length; >> + unsigned int flags; >> + int fd; >> + bool is_secure; >> + void *secure_ctx; >> +}; >> + >> +/** >> + * struct smaf_device - smaf device node private data >> + * @misc_dev: the misc device >> + * @head: list of allocator >> + * @lock: list and secure pointer mutex >> + * @secure: pointer to secure functions helpers >> + */ >> +struct smaf_device { >> + struct miscdevice misc_dev; >> + struct list_head head; >> + /* list and secure pointer lock*/ >> + struct mutex lock; >> + struct smaf_secure *secure; >> +}; >> + >> +static struct smaf_device smaf_dev; >> + >> +/** >> + * smaf_allow_cpu_access return true if CPU can access to memory >> + * if their is no secure module associated to SMAF assume that CPU can >> get >> + * access to the memory. >> + */ >> +static bool smaf_allow_cpu_access(struct smaf_handle *handle, >> + unsigned long flags) >> +{ >> + if (!handle->is_secure) >> + return true; >> + >> + if (!smaf_dev.secure) >> + return true; >> + >> + if (!smaf_dev.secure->allow_cpu_access) >> + return true; >> + >> + return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, >> flags); >> +} >> + >> +static int smaf_grant_access(struct smaf_handle *handle, struct device >> *dev, >> + dma_addr_t addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> + if (!handle->is_secure) >> + return 0; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (!smaf_dev.secure->grant_access) >> + return -EINVAL; >> + >> + return smaf_dev.secure->grant_access(handle->secure_ctx, >> + dev, addr, size, dir); >> +} >> + >> +static void smaf_revoke_access(struct smaf_handle *handle, struct device >> *dev, >> + dma_addr_t addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> + if (!handle->is_secure) >> + return; >> + >> + if (!smaf_dev.secure) >> + return; >> + >> + if (!smaf_dev.secure->revoke_access) >> + return; >> + >> + smaf_dev.secure->revoke_access(handle->secure_ctx, >> + dev, addr, size, dir); >> +} >> + >> +static int smaf_secure_handle(struct smaf_handle *handle) >> +{ >> + if (handle->is_secure) >> + return 0; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (!smaf_dev.secure->create_context) >> + return -EINVAL; >> + >> + handle->secure_ctx = smaf_dev.secure->create_context(); >> + >> + if (!handle->secure_ctx) >> + return -EINVAL; >> + >> + handle->is_secure = true; >> + return 0; >> +} >> + >> +static int smaf_unsecure_handle(struct smaf_handle *handle) >> +{ >> + if (!handle->is_secure) >> + return 0; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (!smaf_dev.secure->destroy_context) >> + return -EINVAL; >> + >> + if (smaf_dev.secure->destroy_context(handle->secure_ctx)) >> + return -EINVAL; >> + >> + handle->secure_ctx = NULL; >> + handle->is_secure = false; >> + return 0; >> +} > > > All these functions need to be protected by a lock, otherwise the > secure state could change. For that matter, I think the smaf_handle > needs a lock to protect its state as well for places like map_dma_buf > >> > <snip> > >> +static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long >> arg) >> +{ >> + switch (cmd) { >> + case SMAF_IOC_CREATE: >> + { >> + struct smaf_create_data data; >> + struct smaf_handle *handle; >> + >> + if (copy_from_user(&data, (void __user *)arg, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + >> + handle = smaf_create_handle(data.length, data.flags); >> + if (!handle) >> + return -EINVAL; >> + >> + if (data.name[0]) { >> + /* user force allocator selection */ >> + if (smaf_select_allocator_by_name(handle->dmabuf, >> + data.name)) { >> + dma_buf_put(handle->dmabuf); >> + return -EINVAL; >> + } >> + } >> + >> + handle->fd = dma_buf_fd(handle->dmabuf, data.flags); >> + if (handle->fd < 0) { >> + dma_buf_put(handle->dmabuf); >> + return -EINVAL; >> + } >> + >> + data.fd = handle->fd; >> + if (copy_to_user((void __user *)arg, &data, >> _IOC_SIZE(cmd))) { >> + dma_buf_put(handle->dmabuf); >> + return -EFAULT; >> + } >> + break; >> + } >> + case SMAF_IOC_GET_SECURE_FLAG: >> + { >> + struct smaf_secure_flag data; >> + struct dma_buf *dmabuf; >> + >> + if (copy_from_user(&data, (void __user *)arg, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + >> + dmabuf = dma_buf_get(data.fd); >> + if (!dmabuf) >> + return -EINVAL; >> + >> + data.secure = smaf_is_secure(dmabuf); >> + dma_buf_put(dmabuf); >> + >> + if (copy_to_user((void __user *)arg, &data, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + break; >> + } >> + case SMAF_IOC_SET_SECURE_FLAG: >> + { >> + struct smaf_secure_flag data; >> + struct dma_buf *dmabuf; >> + int ret; >> + >> + if (!smaf_dev.secure) >> + return -EINVAL; >> + >> + if (copy_from_user(&data, (void __user *)arg, >> _IOC_SIZE(cmd))) >> + return -EFAULT; >> + >> + dmabuf = dma_buf_get(data.fd); >> + if (!dmabuf) >> + return -EINVAL; >> + >> + ret = smaf_set_secure(dmabuf, data.secure); >> + >> + dma_buf_put(dmabuf); >> + >> + if (ret) >> + return -EINVAL; >> + >> + break; >> + } >> + default: >> + return -EINVAL; >> + } >> + >> + return 0; >> +} > > > How would you see this tying into something like Ion? It seems like > Ion and SMAF have non-zero over lapping functionality for some things > or that SMAF could be implemented as a heap type. I think my biggest > concern here is that it seems like either Ion or SMAF is going to feel > redundant as an interface. > > Thanks, > Laura -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

9 years, 8 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v4 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

I have mind few uses cases: - the basic one when an HW device need contiguous memory. - I have a device that could not cross some memory boundaries so I need a specific allocator for it. - when allocating memory for security some platform have address constraints or need to allocate memory in specific areas (most of the time because of firewall limited capacities in terms of regions) 2015-10-06 4:07 GMT+02:00 Laura Abbott <labbott(a)redhat.com>: > On 10/05/2015 03:11 AM, Benjamin Gaignard wrote: >> >> version 4 changes: >> - rebased on kernel 4.3-rc3 >> - fix missing EXPORT_SYMBOL for smaf_create_handle() >> >> version 3 changes: >> - Remove ioctl for allocator selection instead provide the name of >> the targeted allocator with allocation request. >> Selecting allocator from userland isn't the prefered way of working >> but is needed when the first user of the buffer is a software >> component. >> - Fix issues in case of error while creating smaf handle. >> - Fix module license. >> - Update libsmaf and tests to care of the SMAF API evolution >> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git >> >> version 2 changes: >> - Add one ioctl to allow allocator selection from userspace. >> This is required for the uses case where the first user of >> the buffer is a software IP which can't perform dma_buf attachement. >> - Add name and ranking to allocator structure to be able to sort them. >> - Create a tiny library to test SMAF: >> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git >> - Fix one issue when try to secure buffer without secure module >> registered >> >> The outcome of the previous RFC about how do secure data path was the need >> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) >> >> SMAF goal is to provide a framework that allow allocating and securing >> memory by using dma_buf. Each platform have it own way to perform those >> two >> features so SMAF design allow to register helper modules to perform them. >> >> To be sure to select the best allocation method for devices SMAF implement >> deferred allocation mechanism: memory allocation is only done when the >> first >> device effectively required it. >> Allocator modules have to implement a match() to let SMAF know if they are >> compatibles with devices needs. >> This patch set provide an example of allocator module which use >> dma_{alloc/free/mmap}_attrs() and check if at least one device have >> coherent_dma_mask set to DMA_BIT_MASK(32) in match function. >> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if >> a better name could be found for this file. >> >> Secure modules are responsibles of granting and revoking devices access >> rights >> on the memory. Secure module is also called to check if CPU map memory >> into >> kernel and user address spaces. >> An example of secure module implementation can be found here: >> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git >> This code isn't yet part of the patch set because it depends on generic >> TEE >> which is still under discussion (https://lwn.net/Articles/644646/) >> >> For allocation part of SMAF code I get inspirated by Sumit Semwal work >> about >> constraint aware allocator. >> > > Overall I like the abstraction. Do you have a use case in mind right now for > the best allocation method? Some of the classic examples (mmu vs. no mmu) > are gradually becoming less relevant as the systems have evolved. I was > discussing constraints with Sumit w.r.t. Ion at plumbers so I'm curious > about > your uses. > > Thanks, > Laura > > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

9 years, 8 months

1
0
0 0

[PATCH v4 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

version 4 changes: - rebased on kernel 4.3-rc3 - fix missing EXPORT_SYMBOL for smaf_create_handle() version 3 changes: - Remove ioctl for allocator selection instead provide the name of the targeted allocator with allocation request. Selecting allocator from userland isn't the prefered way of working but is needed when the first user of the buffer is a software component. - Fix issues in case of error while creating smaf handle. - Fix module license. - Update libsmaf and tests to care of the SMAF API evolution https://git.linaro.org/people/benjamin.gaignard/libsmaf.git version 2 changes: - Add one ioctl to allow allocator selection from userspace. This is required for the uses case where the first user of the buffer is a software IP which can't perform dma_buf attachement. - Add name and ranking to allocator structure to be able to sort them. - Create a tiny library to test SMAF: https://git.linaro.org/people/benjamin.gaignard/libsmaf.git - Fix one issue when try to secure buffer without secure module registered The outcome of the previous RFC about how do secure data path was the need of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) SMAF goal is to provide a framework that allow allocating and securing memory by using dma_buf. Each platform have it own way to perform those two features so SMAF design allow to register helper modules to perform them. To be sure to select the best allocation method for devices SMAF implement deferred allocation mechanism: memory allocation is only done when the first device effectively required it. Allocator modules have to implement a match() to let SMAF know if they are compatibles with devices needs. This patch set provide an example of allocator module which use dma_{alloc/free/mmap}_attrs() and check if at least one device have coherent_dma_mask set to DMA_BIT_MASK(32) in match function. I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if a better name could be found for this file. Secure modules are responsibles of granting and revoking devices access rights on the memory. Secure module is also called to check if CPU map memory into kernel and user address spaces. An example of secure module implementation can be found here: http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git This code isn't yet part of the patch set because it depends on generic TEE which is still under discussion (https://lwn.net/Articles/644646/) For allocation part of SMAF code I get inspirated by Sumit Semwal work about constraint aware allocator. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 736 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 72 ++++ include/uapi/linux/smaf.h | 52 +++ 9 files changed, 1130 insertions(+) create mode 100644 drivers/smaf/Kconfig create mode 100644 drivers/smaf/Makefile create mode 100644 drivers/smaf/smaf-cma.c create mode 100644 drivers/smaf/smaf-core.c create mode 100644 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

9 years, 8 months

1
2
0 0

[PATCH weston v2 0/8] Generic Wayland dmabuf protocol

by Pekka Paalanen

From: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Hi all, here is the v2 iteration of the Wayland protocol extension for generic sharing of dmabufs between clients and the compositor. The RFCv1 can be found at http://lists.freedesktop.org/archives/wayland-devel/2014-December/019006.ht… The related tracking bug is https://bugs.freedesktop.org/show_bug.cgi?id=83881 The major changes compared to RFCv1 are: - use drm_fourcc.h to define format codes - support FB modifiers and y-flip - simplified protocol - improved documentation - flags for interlaced buffer content As you can see, we have dropped the "RFC" status from this series now. We think this is in a good enough shape to be merged into Weston as an experimental protocol and implementation. Obviously we are still lacking on: - agreed ways to flush caches (what can we cache? EGLImages? DRM FBs?) - enumerating supported formats - supported FB modifiers? - do all imports in compositor before-hand, not as-needed (the import as DRM FB) - EGL doesn't support dmabuf import with modifiers yet - a test application not specific to (Intel) hardware (vivid?) - compositor-drm.c's import of dmabuf needs a rewrite to bypass GBM (to be done after atomic lands) - compositor-drm.c support for multi-planar buffers This patch series is also available at: https://git.collabora.com/cgit/user/pq/weston.git/log/?h=dmabuf-v2 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Louis-Francis Ratté-Boulianne <lfrb(a)collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Axel Davy <axel.davy(a)ens.fr> Cc: linaro-mm-sig(a)lists.linaro.org Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Thomas Hellstrom <thellstrom(a)vmware.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: George Kiagiadakis <george.kiagiadakis(a)collabora.com> George Kiagiadakis (1): clients: add simple-dmabuf client Louis-Francis Ratté-Boulianne (1): gl-renderer: introduce struct egl_image Pekka Paalanen (6): protocol: add linux_dmabuf extension (v2) dmabuf: implement linux_dmabuf extension gl-renderer: add dmabuf import compositor-x11: init linux_dmabuf support compositor-drm: init linux_dmabuf support compositor-drm: dmabuf GBM import .gitignore | 1 + Makefile.am | 25 +- clients/simple-dmabuf.c | 591 ++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 10 + protocol/linux-dmabuf.xml | 279 ++++++++++++++++++++++ src/compositor-drm.c | 49 +++- src/compositor-x11.c | 7 + src/compositor.c | 28 +++ src/compositor.h | 9 + src/gl-renderer.c | 303 +++++++++++++++++++++++- src/linux-dmabuf.c | 497 ++++++++++++++++++++++++++++++++++++++ src/linux-dmabuf.h | 84 +++++++ src/weston-egl-ext.h | 16 ++ 13 files changed, 1885 insertions(+), 14 deletions(-) create mode 100644 clients/simple-dmabuf.c create mode 100644 protocol/linux-dmabuf.xml create mode 100644 src/linux-dmabuf.c create mode 100644 src/linux-dmabuf.h -- 2.3.6 Thanks, pq

9 years, 9 months

2
1
0 0

[PATCH v3 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

version 3 changes: - Remove ioctl for allocator selection instead provide the name of the targeted allocator with allocation request. Selecting allocator from userland isn't the prefered way of working but is needed when the first user of the buffer is a software component. - Fix issues in case of error while creating smaf handle. - Fix module license. - Update libsmaf and tests to care of the SMAF API evolution https://git.linaro.org/people/benjamin.gaignard/libsmaf.git version 2 changes: - Add one ioctl to allow allocator selection from userspace. This is required for the uses case where the first user of the buffer is a software IP which can't perform dma_buf attachement. - Add name and ranking to allocator structure to be able to sort them. - Create a tiny library to test SMAF: https://git.linaro.org/people/benjamin.gaignard/libsmaf.git - Fix one issue when try to secure buffer without secure module registered The outcome of the previous RFC about how do secure data path was the need of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) SMAF goal is to provide a framework that allow allocating and securing memory by using dma_buf. Each platform have it own way to perform those two features so SMAF design allow to register helper modules to perform them. To be sure to select the best allocation method for devices SMAF implement deferred allocation mechanism: memory allocation is only done when the first device effectively required it. Allocator modules have to implement a match() to let SMAF know if they are compatibles with devices needs. This patch set provide an example of allocator module which use dma_{alloc/free/mmap}_attrs() and check if at least one device have coherent_dma_mask set to DMA_BIT_MASK(32) in match function. I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if a better name could be found for this file. Secure modules are responsibles of granting and revoking devices access rights on the memory. Secure module is also called to check if CPU map memory into kernel and user address spaces. An example of secure module implementation can be found here: http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git This code isn't yet part of the patch set because it depends on generic TEE which is still under discussion (https://lwn.net/Articles/644646/) For allocation part of SMAF code I get inspirated by Sumit Semwal work about constraint aware allocator. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 735 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 52 +++ 9 files changed, 1119 insertions(+) create mode 100644 drivers/smaf/Kconfig create mode 100644 drivers/smaf/Makefile create mode 100644 drivers/smaf/smaf-cma.c create mode 100644 drivers/smaf/smaf-core.c create mode 100644 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

9 years, 10 months

2
5
0 0

Re: [Linaro-mm-sig] [PATCH v2 1/2] create SMAF module

by Benjamin Gaignard

I will change the ident in the macro. Thanks, Benjamin 2015-07-07 9:59 GMT+02:00 Paul Bolle <pebolle(a)tiscali.nl>: > A nit only, I'm afraid: a license mismatch. > > On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote: > > --- /dev/null > > +++ b/drivers/smaf/smaf-core.c > > > + * License terms: GNU General Public License (GPL), version 2 > > > +MODULE_LICENSE("GPL"); > > The comment at the top of this file states, succinctly, that the license > is GPL v2. And, according to include/linux/module.h, the > MODULE_LICENSE() macro here states that the license is GPL v2 or later. > So I think that either that comment or the ident used in that macro > needs to change. > > Ditto for 2/2. > > Thanks, > > > Paul Bolle > -- Benjamin Gaignard Graphic Working Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter <http://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-blog/>

9 years, 11 months

1
0
0 0

[PATCH v2 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

version 2 changes: - Add one ioctl to allow allocator selection from userspace. This is required for the uses case where the first user of the buffer is a software IP which can't perform dma_buf attachement. - Add name and ranking to allocator structure to be able to sort them. - Create a tiny library to test SMAF: https://git.linaro.org/people/benjamin.gaignard/libsmaf.git - Fix one issue when try to secure buffer without secure module registered The outcome of the previous RFC about how do secure data path was the need of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) SMAF goal is to provide a framework that allow allocating and securing memory by using dma_buf. Each platform have it own way to perform those two features so SMAF design allow to register helper modules to perform them. To be sure to select the best allocation method for devices SMAF implement deferred allocation mechanism: memory allocation is only done when the first device effectively required it. Allocator modules have to implement a match() to let SMAF know if they are compatibles with devices needs. This patch set provide an example of allocator module which use dma_{alloc/free/mmap}_attrs() and check if at least one device have coherent_dma_mask set to DMA_BIT_MASK(32) in match function. I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if a better name could be found for this file. Secure modules are responsibles of granting and revoking devices access rights on the memory. Secure module is also called to check if CPU map memory into kernel and user address spaces. An example of secure module implementation can be found here: http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git This code isn't yet part of the patch set because it depends on generic TEE which is still under discussion (https://lwn.net/Articles/644646/) For allocation part of SMAF code I get inspirated by Sumit Semwal work about constraint aware allocator. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 200 +++++++++++ drivers/smaf/smaf-core.c | 751 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 54 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 61 ++++ 9 files changed, 1144 insertions(+) create mode 100644 drivers/smaf/Kconfig create mode 100644 drivers/smaf/Makefile create mode 100644 drivers/smaf/smaf-cma.c create mode 100644 drivers/smaf/smaf-core.c create mode 100644 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

9 years, 11 months

1
2
0 0

[GIT PULL]: dma-buf changes for 4.2

by Sumit Semwal

Hi Linus, Very small pull request on dma-buf for 4.2 merge window. May I request you to please pull? The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-4.2 for you to fetch changes up to 5136629dc5a19701746abd7c8ad98ce0b84dda1d: dma-buf: Minor coding style fixes (2015-05-21 11:29:59 +0530) ---------------------------------------------------------------- Minor changes for 4.2 - add ref-counting for kernel modules as exporters - minor code style fixes ---------------------------------------------------------------- Jagan Teki (1): dma-buf: Minor coding style fixes Sumit Semwal (1): dma-buf: add ref counting for module as exporter drivers/dma-buf/dma-buf.c | 19 ++++++++++++++++--- drivers/dma-buf/reservation.c | 9 ++++++--- drivers/dma-buf/seqno-fence.c | 8 +++++++- include/linux/dma-buf.h | 10 ++++++++-- 4 files changed, 37 insertions(+), 9 deletions(-) Thanks and best regards, Sumit.

9 years, 11 months

1
0
0 0

[PATCH 0/2] RFC: Secure Memory Allocation Framework

by Benjamin Gaignard

The outcome of the previous RFC about how do secure data path was the need of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) SMAF goal is to provide a framework that allow allocating and securing memory by using dma_buf. Each platform have it own way to perform those two features so SMAF design allow to register helper modules to perform them. To be sure to select the best allocation method for devices SMAF implement deferred allocation mechanism: memory allocation is only done when the first device effectively required it. Allocator modules have to implement a match() to let SMAF know if they are compatibles with devices needs. This patch set provide an example of allocator module which use dma_{alloc/free/mmap}_attrs() and check if at least one device have coherent_dma_mask set to DMA_BIT_MASK(32) in match function. I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if a better name could be found for this file. Secure modules are responsibles of granting and revoking devices access rights on the memory. Secure module is also called to check if CPU map memory into kernel and user address spaces. An example of secure module implementation can be found here: http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git This code isn't yet part of the patch set because it depends on generic TEE which is still under discussion (https://lwn.net/Articles/644646/) For allocation part of SMAF code I get inspirated by Sumit Semwal work about constraint aware allocator. Benjamin Gaignard (2): create SMAF module SMAF: add CMA allocator drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 11 + drivers/smaf/Makefile | 2 + drivers/smaf/smaf-cma.c | 198 ++++++++++++ drivers/smaf/smaf-core.c | 674 +++++++++++++++++++++++++++++++++++++++++ include/linux/smaf-allocator.h | 43 +++ include/linux/smaf-secure.h | 62 ++++ include/uapi/linux/smaf.h | 48 +++ 9 files changed, 1041 insertions(+) create mode 100644 drivers/smaf/Kconfig create mode 100644 drivers/smaf/Makefile create mode 100644 drivers/smaf/smaf-cma.c create mode 100644 drivers/smaf/smaf-core.c create mode 100644 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

9 years, 11 months

1
2
0 0

[RFCv3 1/2] device: add dma_params->max_segment_count

by Sumit Semwal

From: Rob Clark <robdclark(a)gmail.com> For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation is for devices sharing buffers via dma-buf, to allow the buffer exporter to know the constraints of other devices which have attached to the buffer. The dma_mask and fields in 'struct device_dma_parameters' tell the exporter everything else that is needed, except whether the importer has constraints about maximum number of segments. Signed-off-by: Rob Clark <robdclark(a)gmail.com> [sumits: Minor updates wrt comments] Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> --- v3: include Robin Murphy's fix[1] for handling '0' as a value for max_segment_count v2: minor updates wrt comments on the first version [1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/ include/linux/device.h | 1 + include/linux/dma-mapping.h | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/include/linux/device.h b/include/linux/device.h index fb506738f7b7..a32f9b67315c 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -647,6 +647,7 @@ struct device_dma_parameters { * sg limitations. */ unsigned int max_segment_size; + unsigned int max_segment_count; /* INT_MAX for unlimited */ unsigned long segment_boundary_mask; }; diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index c3007cb4bfa6..d3351a36d5ec 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct device *dev, return -EIO; } +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX) + +static inline unsigned int dma_get_max_seg_count(struct device *dev) +{ + if (dev->dma_parms && dev->dma_parms->max_segment_count) + return dev->dma_parms->max_segment_count; + return DMA_SEGMENTS_MAX_SEG_COUNT; +} + +static inline int dma_set_max_seg_count(struct device *dev, + unsigned int count) +{ + if (dev->dma_parms) { + dev->dma_parms->max_segment_count = count; + return 0; + } + return -EIO; +} + static inline unsigned long dma_get_seg_boundary(struct device *dev) { return dev->dma_parms ? -- 1.9.1

10 years

9
62
0 0

[PATCH v7 00/25] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, This is yet another attempt to get Exynos SYSMMU driver with integrated with IOMMU & DMA-mapping subsystems. This version includes minor fixes suggested by Joerg Roedel, Cho KyongHo and Robin Murphy. All patches are also available in the following git repository: https://git.linaro.org/people/marek.szyprowski/linux-srpol.git branch v4.1-exynos-iommu-v7. My plan for merging this patchset is as follows: - DTS changes and power domain changes should go via Samsung tree to avoid conflicts with other pending DTS patches - all exynos-iommu patches and dma-mapping/reserved iommu region should go via IOMMU tree, - all Exynos DRM patches should go via DRM/Exynos tree. There are no build cross-subsystem dependencies and IOMMU on Exynos is already nonfunctional (and disabled in defconfig), so merging patches in parts doesn't break anything. There are knowns issues with Exynos DRM driver and IOMMU support (i.e. Xorg freeze reported by Javier Martinez Canillas: http://www.spinics.net/lists/linux-samsung-soc/msg44350.html ). They will be handled by a separate fixes to Exynos DRM drivers. This patchset fixes only those issues in Exynos DRM FIMD driver, which prevents booting to console. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v7: - rebased onto v4.1-rc4 - restored iommu_gruops support - added missing suspend/resume support patch - rearanged patch order and squashed some patches for better code readability - changed patch prefixes to match maintainer's requirements - fixed minor issues pointed by Joerg Roedel, Cho KyongHo and Robin Murphy - added Krzysztof's acks for dts patches v6: http://www.spinics.net/lists/linux-samsung-soc/msg44065.html - rebased onto v4.1-rc2 with 'arm: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops' patch - added exynos 3250 and 4415 dts patches - added support for devices, which have been left enabled by bootloader (i.e. framebuffer displaying slash screen) - fixed freeze in fimd iommu initialization caused by lack of proper runtime pm management - resolved issues with power domains by moving pd initialization to core_initcall v5: https://lists.linaro.org/pipermail/linaro-mm-sig/2015-February/004442.html - rebased onto 'Add HDMI support for Exynos5420 platform' patchset - fixed 'const' issue in 'iommu: exynos: init from dt-specific callback instead of initcall' patch, thanks to Tobias Jakobi for reporting it - fixed copy-paste typo in exynos5250 dts patch v4: http://www.spinics.net/lists/linux-samsung-soc/msg41177.html - rebased onto v3.19-rc4 and other Exynos DTS queued patches - added DTS patch for Exynos 5250 & 5420/5422/5800 v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html - rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters" - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (25): drm/exynos: iommu: detach from default dma-mapping domain on init drm/exynos: fimd: ensure proper hw state in fimd_clear_channel() iommu: Init iommu-groups support earlier, in core_initcall iommu/exynos: Don't read version register on every tlb operation iommu/exynos: Remove unused functions iommu/exynos: Remove useless members from exynos_iommu_owner structure iommu/exynos: Refactor function parameters to simplify code iommu/exynos: Rename variables to reflect their purpose iommu/exynos: Use struct exynos_iommu_domain in internal structures iommu/exynos: Remove excessive includes and sort others alphabetically iommu/exynos: Document internal structures iommu/exynos: Add/remove callbacks should fail if no iommu is available iommu/exynos: Add support for binding more than one sysmmu to master device iommu/exynos: Add support for runtime_pm iommu/exynos: Add system suspend/resume support iommu/exynos: Init from dt-specific callback instead of initcall iommu/exynos: Add callback for initializing devices from device tree ARM: Exynos: pm_domains: register power domain driver from core_initcall ARM: dts: exynos4: add sysmmu nodes ARM: dts: exynos3250: add sysmmu nodes ARM: dts: exynos4415: add sysmmu nodes ARM: dts: exynos5250: add sysmmu nodes ARM: dts: exynos5420: add sysmmu nodes ARM: DMA-mapping: add support for creating reserved mappings in iova space ARM: dts: exynos: add iommu reserved regions for bootloader's splash screen Documentation/devicetree/bindings/iommu/iommu.txt | 44 ++ arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos3250.dtsi | 22 + arch/arm/boot/dts/exynos4.dtsi | 118 +++++ arch/arm/boot/dts/exynos4210-trats.dts | 1 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 1 + arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4412-trats2.dts | 1 + arch/arm/boot/dts/exynos4415.dtsi | 11 + arch/arm/boot/dts/exynos4x12.dtsi | 82 ++++ arch/arm/boot/dts/exynos5250-snow.dts | 1 + arch/arm/boot/dts/exynos5250-spring.dts | 1 + arch/arm/boot/dts/exynos5250.dtsi | 250 ++++++++++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + arch/arm/boot/dts/exynos5420.dtsi | 181 ++++++++ arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + arch/arm/mach-exynos/pm_domains.c | 18 +- arch/arm/mm/dma-mapping.c | 121 +++++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 526 +++++++++++----------- drivers/iommu/iommu.c | 2 +- 22 files changed, 1156 insertions(+), 280 deletions(-) -- 1.9.2

10 years

6
32
0 0

[PATCH] dma-buf: Minor coding style fixes

by Jagan Teki

- WARNING: Missing a blank line after declarations - WARNING: line over 80 characters - WARNING: please, no space before tabs Signed-off-by: Jagan Teki <jteki(a)openedev.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> --- drivers/dma-buf/dma-buf.c | 9 +++++++-- drivers/dma-buf/reservation.c | 9 ++++++--- drivers/dma-buf/seqno-fence.c | 8 +++++++- 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index c5a9138..30a099c 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -285,6 +285,7 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) struct reservation_object *resv = exp_info->resv; struct file *file; size_t alloc_size = sizeof(struct dma_buf); + if (!exp_info->resv) alloc_size += sizeof(struct reservation_object); else @@ -545,7 +546,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, return -EINVAL; if (dmabuf->ops->begin_cpu_access) - ret = dmabuf->ops->begin_cpu_access(dmabuf, start, len, direction); + ret = dmabuf->ops->begin_cpu_access(dmabuf, start, + len, direction); return ret; } @@ -649,7 +651,7 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap); * @dmabuf: [in] buffer that should back the vma * @vma: [in] vma for the mmap * @pgoff: [in] offset in pages where this mmap should start within the - * dma-buf buffer. + * dma-buf buffer. * * This function adjusts the passed in vma so that it points at the file of the * dma_buf operation. It also adjusts the starting pgoff and does bounds @@ -826,6 +828,7 @@ static int dma_buf_describe(struct seq_file *s) static int dma_buf_show(struct seq_file *s, void *unused) { void (*func)(struct seq_file *) = s->private; + func(s); return 0; } @@ -847,7 +850,9 @@ static struct dentry *dma_buf_debugfs_dir; static int dma_buf_init_debugfs(void) { int err = 0; + dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL); + if (IS_ERR(dma_buf_debugfs_dir)) { err = PTR_ERR(dma_buf_debugfs_dir); dma_buf_debugfs_dir = NULL; diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 39920d7..c0bd572 100644 --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -337,7 +337,8 @@ retry: rcu_read_lock(); if (wait_all) { - struct reservation_object_list *fobj = rcu_dereference(obj->fence); + struct reservation_object_list *fobj = + rcu_dereference(obj->fence); if (fobj) shared_count = fobj->shared_count; @@ -429,7 +430,8 @@ retry: if (test_all) { unsigned i; - struct reservation_object_list *fobj = rcu_dereference(obj->fence); + struct reservation_object_list *fobj = + rcu_dereference(obj->fence); if (fobj) shared_count = fobj->shared_count; @@ -462,7 +464,8 @@ retry: goto unlock_retry; if (fence_excl) { - ret = reservation_object_test_signaled_single(fence_excl); + ret = reservation_object_test_signaled_single( + fence_excl); if (ret < 0) goto unlock_retry; } diff --git a/drivers/dma-buf/seqno-fence.c b/drivers/dma-buf/seqno-fence.c index 7d12a39..71127f8 100644 --- a/drivers/dma-buf/seqno-fence.c +++ b/drivers/dma-buf/seqno-fence.c @@ -24,24 +24,28 @@ static const char *seqno_fence_get_driver_name(struct fence *fence) { struct seqno_fence *seqno_fence = to_seqno_fence(fence); + return seqno_fence->ops->get_driver_name(fence); } static const char *seqno_fence_get_timeline_name(struct fence *fence) { struct seqno_fence *seqno_fence = to_seqno_fence(fence); + return seqno_fence->ops->get_timeline_name(fence); } static bool seqno_enable_signaling(struct fence *fence) { struct seqno_fence *seqno_fence = to_seqno_fence(fence); + return seqno_fence->ops->enable_signaling(fence); } static bool seqno_signaled(struct fence *fence) { struct seqno_fence *seqno_fence = to_seqno_fence(fence); + return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence); } @@ -56,9 +60,11 @@ static void seqno_release(struct fence *fence) fence_free(&f->base); } -static signed long seqno_wait(struct fence *fence, bool intr, signed long timeout) +static signed long seqno_wait(struct fence *fence, bool intr, + signed long timeout) { struct seqno_fence *f = to_seqno_fence(fence); + return f->ops->wait(fence, intr, timeout); } -- 1.9.1

10 years

2
1
0 0

[PATCH v6 00/25] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, This is yet another attempt to get Exynos SYSMMU driver with integrated with IOMMU & DMA-mapping subsystems. The main change from previous version is addition of the patches to define iommu-mapping, which need to be created during system boot to avoid IOMMU fault by devices, which has been left enabled by bootloader (i.e. framebuffer displaying slash screen). Patches has been also rebased onto v4.1-rc2 with 'arm: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops' patch applied (see commit 1424532b2163bf1580f4b1091a5801e12310fac5 on fixes branch in git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git, more information: http://www.spinics.net/lists/arm-kernel/msg414722.html). All patches are also available in the following git repository: https://git.linaro.org/people/marek.szyprowski/linux-srpol.git branch v4.1-exynos-iommu. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v6: - rebased onto v4.1-rc2 with 'arm: dma-mapping: fix off-by-one check in arm_setup_iommu_dma_ops' patch - added exynos 3250 and 4415 dts patches - added support for devices, which have been left enabled by bootloader (i.e. framebuffer displaying slash screen) - fixed freeze in fimd iommu initialization caused by lack of proper runtime pm management - resolved issues with power domains by moving pd initialization to core_initcall v5: https://lists.linaro.org/pipermail/linaro-mm-sig/2015-February/004442.html - rebased onto 'Add HDMI support for Exynos5420 platform' patchset - fixed 'const' issue in 'iommu: exynos: init from dt-specific callback instead of initcall' patch, thanks to Tobias Jakobi for reporting it - fixed copy-paste typo in exynos5250 dts patch v4: http://www.spinics.net/lists/linux-samsung-soc/msg41177.html - rebased onto v3.19-rc4 and other Exynos DTS queued patches - added DTS patch for Exynos 5250 & 5420/5422/5800 v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html - rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters" - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (25): arm: dma-mapping: add support for creating reserved mappings in iova space arm: exynos: pm_domains: register power domain driver from core_initcall drm/exynos: iommu: detach from default dma-mapping domain on init drm/exynos: fimd: ensure proper hw state in fimd_clear_channel() iommu: exynos: don't read version register on every tlb operation iommu: exynos: remove unused functions iommu: exynos: remove useless spinlock iommu: exynos: refactor function parameters to simplify code iommu: exynos: remove unused functions, part 2 iommu: exynos: remove useless device_add/remove callbacks iommu: exynos: add support for binding more than one sysmmu to master device iommu: exynos: add support for runtime_pm iommu: exynos: rename variables to reflect their purpose iommu: exynos: use struct exynos_iommu_domain in internal structures iommu: exynos: document internal structures iommu: exynos: remove excessive includes and sort others alphabetically iommu: exynos: init from dt-specific callback instead of initcall iommu: exynos: add callback for initializing devices from device tree iommu: exynos: remove unneeded code ARM: dts: exynos4: add sysmmu nodes ARM: dts: exynos3250: add sysmmu nodes ARM: dts: exynos4415: add sysmmu nodes ARM: dts: exynos5250: add sysmmu nodes ARM: dts: exynos5420: add sysmmu nodes ARM: dts: exynos: add iommu reserved regions for bootloader's splash screen Documentation/devicetree/bindings/iommu/iommu.txt | 44 ++ arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos3250.dtsi | 22 + arch/arm/boot/dts/exynos4.dtsi | 118 ++++++ arch/arm/boot/dts/exynos4210-trats.dts | 1 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 1 + arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4412-trats2.dts | 1 + arch/arm/boot/dts/exynos4415.dtsi | 11 + arch/arm/boot/dts/exynos4x12.dtsi | 82 ++++ arch/arm/boot/dts/exynos5250-snow.dts | 1 + arch/arm/boot/dts/exynos5250-spring.dts | 1 + arch/arm/boot/dts/exynos5250.dtsi | 250 +++++++++++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + arch/arm/boot/dts/exynos5420.dtsi | 181 ++++++++ arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + arch/arm/mach-exynos/pm_domains.c | 18 +- arch/arm/mm/dma-mapping.c | 112 +++++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 495 ++++++++++------------ 21 files changed, 1098 insertions(+), 296 deletions(-) -- 1.9.2

10 years

8
56
0 0

[PATCH v3] dma-buf: add ref counting for module as exporter

by Sumit Semwal

Add reference counting on a kernel module that exports dma-buf and implements its operations. This prevents the module from being unloaded while DMABUF file is in use. The original patch [1] was submitted by Tomasz Stanislawski, but this is a simpler way to do it. v3: call module_put() as late as possible, per gregkh's comment. v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO macro to simplify the change. Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> [1]: https://lkml.org/lkml/2012/8/8/163 --- drivers/dma-buf/dma-buf.c | 10 +++++++++- include/linux/dma-buf.h | 10 ++++++++-- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index c5a9138a6a8d..63a9914e42b8 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -29,6 +29,7 @@ #include <linux/anon_inodes.h> #include <linux/export.h> #include <linux/debugfs.h> +#include <linux/module.h> #include <linux/seq_file.h> #include <linux/poll.h> #include <linux/reservation.h> @@ -72,6 +73,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) if (dmabuf->resv == (struct reservation_object *)&dmabuf[1]) reservation_object_fini(dmabuf->resv); + module_put(dmabuf->owner); kfree(dmabuf); return 0; } @@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return ERR_PTR(-EINVAL); } + if (!try_module_get(exp_info->owner)) + return ERR_PTR(-ENOENT); + dmabuf = kzalloc(alloc_size, GFP_KERNEL); - if (dmabuf == NULL) + if (!dmabuf) { + module_put(exp_info->owner); return ERR_PTR(-ENOMEM); + } dmabuf->priv = exp_info->priv; dmabuf->ops = exp_info->ops; dmabuf->size = exp_info->size; dmabuf->exp_name = exp_info->exp_name; + dmabuf->owner = exp_info->owner; init_waitqueue_head(&dmabuf->poll); dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 2f0b431b73e0..f98bd7068d55 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -115,6 +115,8 @@ struct dma_buf_ops { * @attachments: list of dma_buf_attachment that denotes all devices attached. * @ops: dma_buf_ops associated with this buffer object. * @exp_name: name of the exporter; useful for debugging. + * @owner: pointer to exporter module; used for refcounting when exporter is a + * kernel module. * @list_node: node for dma_buf accounting and debugging. * @priv: exporter specific private data for this buffer object. * @resv: reservation object linked to this dma-buf @@ -129,6 +131,7 @@ struct dma_buf { unsigned vmapping_counter; void *vmap_ptr; const char *exp_name; + struct module *owner; struct list_head list_node; void *priv; struct reservation_object *resv; @@ -164,7 +167,8 @@ struct dma_buf_attachment { /** * struct dma_buf_export_info - holds information needed to export a dma_buf - * @exp_name: name of the exporting module - useful for debugging. + * @exp_name: name of the exporter - useful for debugging. + * @owner: pointer to exporter module - used for refcounting kernel module * @ops: Attach allocator-defined dma buf ops to the new buffer * @size: Size of the buffer * @flags: mode flags for the file @@ -176,6 +180,7 @@ struct dma_buf_attachment { */ struct dma_buf_export_info { const char *exp_name; + struct module *owner; const struct dma_buf_ops *ops; size_t size; int flags; @@ -187,7 +192,8 @@ struct dma_buf_export_info { * helper macro for exporters; zeros and fills in most common values */ #define DEFINE_DMA_BUF_EXPORT_INFO(a) \ - struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME } + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \ + .owner = THIS_MODULE } /** * get_dma_buf - convenience wrapper for get_file. -- 1.9.1

10 years

2
1
0 0

[RESEND PATCH] Smack: ignore private inode for smack_file_receive

by Seung-Woo Kim

The dmabuf fd can be shared between processes via unix domain socket. The file of dmabuf fd is came from anon_inode. The inode has no set and get xattr operations, so it can not be shared between processes with smack. This patch fixes just to ignore private inode including anon_inode for smack_file_receive. Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> --- I think there was some issue sending my previous mail, so I resend patch again. --- security/smack/smack_lsm.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 69fdc38..d1bb411 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -1673,6 +1673,9 @@ static int smack_file_receive(struct file *file) struct smk_audit_info ad; struct inode *inode = file_inode(file); + if (unlikely(IS_PRIVATE(inode))) + return 0; + smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_PATH); smk_ad_setfield_u_fs_path(&ad, file->f_path); /* -- 1.7.4.1

10 years

1
1
0 0

[PATCH v2] dma-buf: add ref counting for module as exporter

by Sumit Semwal

Add reference counting on a kernel module that exports dma-buf and implements its operations. This prevents the module from being unloaded while DMABUF file is in use. The original patch [1] was submitted by Tomasz Stanislawski, but this is a simpler way to do it. v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO macro to simplify the change. Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> [1]: https://lkml.org/lkml/2012/8/8/163 --- drivers/dma-buf/dma-buf.c | 10 +++++++++- include/linux/dma-buf.h | 10 ++++++++-- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index c5a9138a6a8d..0eff4bf56ef6 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -29,6 +29,7 @@ #include <linux/anon_inodes.h> #include <linux/export.h> #include <linux/debugfs.h> +#include <linux/module.h> #include <linux/seq_file.h> #include <linux/poll.h> #include <linux/reservation.h> @@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); dmabuf->ops->release(dmabuf); + module_put(dmabuf->owner); mutex_lock(&db_list.lock); list_del(&dmabuf->list_node); @@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return ERR_PTR(-EINVAL); } + if (!try_module_get(exp_info->owner)) + return ERR_PTR(-ENOENT); + dmabuf = kzalloc(alloc_size, GFP_KERNEL); - if (dmabuf == NULL) + if (!dmabuf) { + module_put(exp_info->owner); return ERR_PTR(-ENOMEM); + } dmabuf->priv = exp_info->priv; dmabuf->ops = exp_info->ops; dmabuf->size = exp_info->size; dmabuf->exp_name = exp_info->exp_name; + dmabuf->owner = exp_info->owner; init_waitqueue_head(&dmabuf->poll); dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 2f0b431b73e0..f98bd7068d55 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -115,6 +115,8 @@ struct dma_buf_ops { * @attachments: list of dma_buf_attachment that denotes all devices attached. * @ops: dma_buf_ops associated with this buffer object. * @exp_name: name of the exporter; useful for debugging. + * @owner: pointer to exporter module; used for refcounting when exporter is a + * kernel module. * @list_node: node for dma_buf accounting and debugging. * @priv: exporter specific private data for this buffer object. * @resv: reservation object linked to this dma-buf @@ -129,6 +131,7 @@ struct dma_buf { unsigned vmapping_counter; void *vmap_ptr; const char *exp_name; + struct module *owner; struct list_head list_node; void *priv; struct reservation_object *resv; @@ -164,7 +167,8 @@ struct dma_buf_attachment { /** * struct dma_buf_export_info - holds information needed to export a dma_buf - * @exp_name: name of the exporting module - useful for debugging. + * @exp_name: name of the exporter - useful for debugging. + * @owner: pointer to exporter module - used for refcounting kernel module * @ops: Attach allocator-defined dma buf ops to the new buffer * @size: Size of the buffer * @flags: mode flags for the file @@ -176,6 +180,7 @@ struct dma_buf_attachment { */ struct dma_buf_export_info { const char *exp_name; + struct module *owner; const struct dma_buf_ops *ops; size_t size; int flags; @@ -187,7 +192,8 @@ struct dma_buf_export_info { * helper macro for exporters; zeros and fills in most common values */ #define DEFINE_DMA_BUF_EXPORT_INFO(a) \ - struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME } + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \ + .owner = THIS_MODULE } /** * get_dma_buf - convenience wrapper for get_file. -- 1.9.1

10 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig