Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

2 participants
3108 discussions

[RFC][PATCH] dma-buf: Introduce dma-buf test module

by Laura Abbott

dma-buf is designed to share buffers. Sharing means that there needs to be another subsystem to accept those buffers. Introduce a simple test module to act as a dummy system to accept dma_bufs from elsewhere. The goal is to provide a very simple interface to validate exported buffers do something reasonable. This is based on ion_test.c that existed for the Ion framework. Signed-off-by: Laura Abbott <labbott(a)redhat.com> --- This is basically a drop in of what was available as drivers/staging/android/ion/ion_test.c. Given it has no Ion specific parts it might be useful as a more general test module. RFC mostly to see if this is generally useful or not. --- drivers/dma-buf/Kconfig | 9 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-test.c | 309 ++++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma_buf_test.h | 67 +++++++++ 4 files changed, 386 insertions(+) create mode 100644 drivers/dma-buf/dma-buf-test.c create mode 100644 include/uapi/linux/dma_buf_test.h diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index ed3b785..8b3fdb1 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -30,4 +30,13 @@ config SW_SYNC WARNING: improper use of this can result in deadlocking kernel drivers from userspace. Intended for test and debug only. +config DMA_BUF_TEST + bool "Test module for dma-buf" + default n + ---help--- + A test module to validate dma_buf APIs. This should not be + enabled for general use. + + Say N here unless you know you want this. + endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index c33bf88..5029608 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,3 +1,4 @@ obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o +obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c new file mode 100644 index 0000000..3af131c --- /dev/null +++ b/drivers/dma-buf/dma-buf-test.c @@ -0,0 +1,309 @@ +/* + * Copyright (C) 2013 Google, Inc. + * + * This software is licensed under the terms of the GNU General Public + * License versdma_buf 2, as published by the Free Software Foundatdma_buf, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#define pr_fmt(fmt) "dma-buf-test: " fmt + +#include <linux/dma-buf.h> +#include <linux/dma-direction.h> +#include <linux/fs.h> +#include <linux/miscdevice.h> +#include <linux/mm.h> +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/sched.h> +#include <linux/slab.h> +#include <linux/uaccess.h> +#include <linux/vmalloc.h> + +#include <uapi/linux/dma_buf_test.h> + +struct dma_buf_test_device { + struct miscdevice misc; +}; + +struct dma_buf_test_data { + struct dma_buf *dma_buf; + struct device *dev; +}; + +static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf *dma_buf, + void __user *ptr, size_t offset, size_t size, + bool write) +{ + int ret = 0; + struct dma_buf_attachment *attach; + struct sg_table *table; + pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL); + enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE; + struct sg_page_iter sg_iter; + unsigned long offset_page; + + attach = dma_buf_attach(dma_buf, dev); + if (IS_ERR(attach)) + return PTR_ERR(attach); + + table = dma_buf_map_attachment(attach, dir); + if (IS_ERR(table)) + return PTR_ERR(table); + + offset_page = offset >> PAGE_SHIFT; + offset %= PAGE_SIZE; + + for_each_sg_page(table->sgl, &sg_iter, table->nents, offset_page) { + struct page *page = sg_page_iter_page(&sg_iter); + void *vaddr = vmap(&page, 1, VM_MAP, pgprot); + size_t to_copy = PAGE_SIZE - offset; + + to_copy = min(to_copy, size); + if (!vaddr) { + ret = -ENOMEM; + goto err; + } + + if (write) + ret = copy_from_user(vaddr + offset, ptr, to_copy); + else + ret = copy_to_user(ptr, vaddr + offset, to_copy); + + vunmap(vaddr); + if (ret) { + ret = -EFAULT; + goto err; + } + size -= to_copy; + if (!size) + break; + ptr += to_copy; + offset = 0; + } + +err: + dma_buf_unmap_attachment(attach, table, dir); + dma_buf_detach(dma_buf, attach); + return ret; +} + +static int dma_buf_handle_test_kernel(struct dma_buf *dma_buf, void __user *ptr, + size_t offset, size_t size, bool write) +{ + int ret; + unsigned long page_offset = offset >> PAGE_SHIFT; + size_t copy_offset = offset % PAGE_SIZE; + size_t copy_size = size; + enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE; + + if (offset > dma_buf->size || size > dma_buf->size - offset) + return -EINVAL; + + ret = dma_buf_begin_cpu_access(dma_buf, dir); + if (ret) + return ret; + + while (copy_size > 0) { + size_t to_copy; + void *vaddr = dma_buf_kmap(dma_buf, page_offset); + + if (!vaddr) + goto err; + + to_copy = min_t(size_t, PAGE_SIZE - copy_offset, copy_size); + + if (write) + ret = copy_from_user(vaddr + copy_offset, ptr, to_copy); + else + ret = copy_to_user(ptr, vaddr + copy_offset, to_copy); + + dma_buf_kunmap(dma_buf, page_offset, vaddr); + if (ret) { + ret = -EFAULT; + goto err; + } + + copy_size -= to_copy; + ptr += to_copy; + page_offset++; + copy_offset = 0; + } +err: + dma_buf_end_cpu_access(dma_buf, dir); + return ret; +} + +static long dma_buf_test_ioctl(struct file *filp, unsigned int cmd, + unsigned long arg) +{ + struct dma_buf_test_data *test_data = filp->private_data; + int ret = 0; + + union { + struct dma_buf_test_rw_data test_rw; + } data; + + if (_IOC_SIZE(cmd) > sizeof(data)) + return -EINVAL; + + if (_IOC_DIR(cmd) & _IOC_WRITE) + if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd))) + return -EFAULT; + + switch (cmd) { + case DMA_BUF_IOC_TEST_SET_FD: + { + struct dma_buf *dma_buf = NULL; + int fd = arg; + + if (fd >= 0) { + dma_buf = dma_buf_get((int)arg); + if (IS_ERR(dma_buf)) + return PTR_ERR(dma_buf); + } + if (test_data->dma_buf) + dma_buf_put(test_data->dma_buf); + test_data->dma_buf = dma_buf; + break; + } + case DMA_BUF_IOC_TEST_DMA_MAPPING: + { + ret = dma_buf_handle_test_dma(test_data->dev, + test_data->dma_buf, + u64_to_user_ptr(data.test_rw.ptr), + data.test_rw.offset, + data.test_rw.size, + data.test_rw.write); + break; + } + case DMA_BUF_IOC_TEST_KERNEL_MAPPING: + { + ret = dma_buf_handle_test_kernel(test_data->dma_buf, + u64_to_user_ptr(data.test_rw.ptr), + data.test_rw.offset, + data.test_rw.size, + data.test_rw.write); + break; + } + default: + return -ENOTTY; + } + + if (_IOC_DIR(cmd) & _IOC_READ) { + if (copy_to_user((void __user *)arg, &data, sizeof(data))) + return -EFAULT; + } + return ret; +} + +static int dma_buf_test_open(struct inode *inode, struct file *file) +{ + struct dma_buf_test_data *data; + struct miscdevice *miscdev = file->private_data; + + data = kzalloc(sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + + data->dev = miscdev->parent; + + file->private_data = data; + + return 0; +} + +static int dma_buf_test_release(struct inode *inode, struct file *file) +{ + struct dma_buf_test_data *data = file->private_data; + + kfree(data); + + return 0; +} + +static const struct file_operations dma_buf_test_fops = { + .owner = THIS_MODULE, + .unlocked_ioctl = dma_buf_test_ioctl, + .compat_ioctl = dma_buf_test_ioctl, + .open = dma_buf_test_open, + .release = dma_buf_test_release, +}; + +static int __init dma_buf_test_probe(struct platform_device *pdev) +{ + int ret; + struct dma_buf_test_device *testdev; + + testdev = devm_kzalloc(&pdev->dev, sizeof(struct dma_buf_test_device), + GFP_KERNEL); + if (!testdev) + return -ENOMEM; + + testdev->misc.minor = MISC_DYNAMIC_MINOR; + testdev->misc.name = "dma_buf-test"; + testdev->misc.fops = &dma_buf_test_fops; + testdev->misc.parent = &pdev->dev; + /* + * We need to force 'something' for a DMA mask. This isn't an actual + * device and won't be doing actual DMA so pick 'something' that + * probably won't blow up. Probably. + */ + dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); + ret = misc_register(&testdev->misc); + if (ret) { + pr_err("failed to register misc device.\n"); + return ret; + } + + platform_set_drvdata(pdev, testdev); + + return 0; +} + +static int dma_buf_test_remove(struct platform_device *pdev) +{ + struct dma_buf_test_device *testdev; + + testdev = platform_get_drvdata(pdev); + if (!testdev) + return -ENODATA; + + misc_deregister(&testdev->misc); + return 0; +} + +static struct platform_device *dma_buf_test_pdev; +static struct platform_driver dma_buf_test_platform_driver = { + .remove = dma_buf_test_remove, + .driver = { + .name = "dma_buf-test", + }, +}; + +static int __init dma_buf_test_init(void) +{ + dma_buf_test_pdev = platform_device_register_simple("dma-buf-test", + -1, NULL, 0); + if (IS_ERR(dma_buf_test_pdev)) + return PTR_ERR(dma_buf_test_pdev); + + return platform_driver_probe(&dma_buf_test_platform_driver, + dma_buf_test_probe); +} + +static void __exit dma_buf_test_exit(void) +{ + platform_driver_unregister(&dma_buf_test_platform_driver); + platform_device_unregister(dma_buf_test_pdev); +} + +module_init(dma_buf_test_init); +module_exit(dma_buf_test_exit); +MODULE_LICENSE("GPL v2"); diff --git a/include/uapi/linux/dma_buf_test.h b/include/uapi/linux/dma_buf_test.h new file mode 100644 index 0000000..af2d521 --- /dev/null +++ b/include/uapi/linux/dma_buf_test.h @@ -0,0 +1,67 @@ +/* + * Copyright (C) 2011 Google, Inc. + * + * This software is licensed under the terms of the GNU General Public + * License versdma_buf 2, as published by the Free Software Foundatdma_buf, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#ifndef _UAPI_LINUX_DMA_BUF_TEST_H +#define _UAPI_LINUX_DMA_BUF_TEST_H + +#include <linux/ioctl.h> +#include <linux/types.h> + +/** + * struct dma_buf_test_rw_data - metadata passed to the kernel to read handle + * @ptr: a pointer to an area at least as large as size + * @offset: offset into the dma_buf buffer to start reading + * @size: size to read or write + * @write: 1 to write, 0 to read + */ +struct dma_buf_test_rw_data { + __u64 ptr; + __u64 offset; + __u64 size; + int write; + int __padding; +}; + +#define DMA_BUF_IOC_MAGIC 'I' + +/** + * DOC: DMA_BUF_IOC_TEST_SET_DMA_BUF - attach a dma buf to the test driver + * + * Attaches a dma buf fd to the test driver. Passing a second fd or -1 will + * release the first fd. + */ +#define DMA_BUF_IOC_TEST_SET_FD \ + _IO(DMA_BUF_IOC_MAGIC, 0xf0) + +/** + * DOC: DMA_BUF_IOC_TEST_DMA_MAPPING - read or write memory from a handle as DMA + * + * Reads or writes the memory from a handle using an uncached mapping. Can be + * used by unit tests to emulate a DMA engine as close as possible. Only + * expected to be used for debugging and testing, may not always be available. + */ +#define DMA_BUF_IOC_TEST_DMA_MAPPING \ + _IOW(DMA_BUF_IOC_MAGIC, 0xf1, struct dma_buf_test_rw_data) + +/** + * DOC: DMA_BUF_IOC_TEST_KERNEL_MAPPING - read or write memory from a handle + * + * Reads or writes the memory from a handle using a kernel mapping. Can be + * used by unit tests to test heap map_kernel functdma_bufs. Only expected to be + * used for debugging and testing, may not always be available. + */ +#define DMA_BUF_IOC_TEST_KERNEL_MAPPING \ + _IOW(DMA_BUF_IOC_MAGIC, 0xf2, struct dma_buf_test_rw_data) + +#endif /* _UAPI_LINUX_DMA_BUF_TEST_H */ -- 2.7.4

8 years, 7 months

Re: [Linaro-mm-sig] [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

by Daniel Vetter

On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote: > On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: > > > No one gave a thing about android in upstream, so Greg KH just dumped it > > all into staging/android/. We've discussed ION a bunch of times, recorded > > anything we'd like to fix in staging/android/TODO, and Laura's patch > > series here addresses a big chunk of that. > > > This is pretty much the same approach we (gpu folks) used to de-stage the > > syncpt stuff. > > Well, there's also the fact that quite a few people have issues with the > design (like Laurent). It seems like a lot of them have either got more > comfortable with it over time, or at least not managed to come up with > any better ideas in the meantime. See the TODO, it has everything a really big group (look at the patch for the full Cc: list) figured needs to be improved at LPC 2015. We don't just merge stuff because merging stuff is fun :-) Laurent was even in that group ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

8 years, 7 months

Re: [Linaro-mm-sig] [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

by Laura Abbott

On 03/13/2017 06:21 AM, Mark Brown wrote: > On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: >> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > >>> Another point is how can we put secure rules (like selinux policy) on >>> heaps since all the allocations >>> go to the same device (/dev/ion) ? For example, until now, in Android >>> we have to give the same >>> access rights to all the process that use ION. >>> It will become problem when we will add secure heaps because we won't >>> be able to distinguish secure >>> processes to standard ones or set specific policy per heaps. >>> Maybe I'm wrong here but I have never see selinux policy checking an >>> ioctl field but if that >>> exist it could be a solution. > >> I might be thinking of a different type of "secure", but... > >> Should the security of secure heaps be enforced by OS-level >> permissions? I don't know about other architectures, but at least on >> arm/arm64 this is enforced in hardware; it doesn't matter who has >> access to the ion heap, because only secure devices (or the CPU >> running a secure process) is physically able to access the memory >> backing the buffer. > 3 >> In fact, in the use-cases I know of, the process asking for the ion >> allocation is not a secure process, and so we wouldn't *want* to >> restrict the secure heap to be allocated from only by secure >> processes. > > I think there's an orthogonal level of OS level security that can be > applied here - it's reasonable for it to want to say things like "only > processes that are supposed to be implementing functionality X should be > able to try to allocate memory set aside for that functionality". This > mitigates against escallation attacks and so on, it's not really > directly related to secure memory as such though. > Ion also makes it pretty trivial to allocate large amounts of kernel memory and possibly DoS the system. I'd like to have as little policy in Ion as possible but more important would be a general security review and people shouting "bad idea ahead". Thanks, Laura

8 years, 7 months

Re: [Linaro-mm-sig] [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

by Laura Abbott

On 03/06/2017 09:00 AM, Emil Velikov wrote: > On 6 March 2017 at 10:29, Daniel Vetter <daniel(a)ffwll.ch> wrote: >> On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote: >>> On 03/03/2017 08:39 AM, Laurent Pinchart wrote: >>>> Hi Daniel, >>>> >>>> On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote: >>>>> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote: >>>>>> Now that we call dma_map in the dma_buf API callbacks there is no need >>>>>> to use the existing cache APIs. Remove the sync ioctl and the existing >>>>>> bad dma_sync calls. Explicit caching can be handled with the dma_buf >>>>>> sync API. >>>>>> >>>>>> Signed-off-by: Laura Abbott <labbott(a)redhat.com> >>>>>> --- >>>>>> >>>>>> drivers/staging/android/ion/ion-ioctl.c | 5 ---- >>>>>> drivers/staging/android/ion/ion.c | 40 -------------------- >>>>>> drivers/staging/android/ion/ion_carveout_heap.c | 6 ---- >>>>>> drivers/staging/android/ion/ion_chunk_heap.c | 6 ---- >>>>>> drivers/staging/android/ion/ion_page_pool.c | 3 -- >>>>>> drivers/staging/android/ion/ion_system_heap.c | 5 ---- >>>>>> 6 files changed, 65 deletions(-) >>>>>> >>>>>> diff --git a/drivers/staging/android/ion/ion-ioctl.c >>>>>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644 >>>>>> --- a/drivers/staging/android/ion/ion-ioctl.c >>>>>> +++ b/drivers/staging/android/ion/ion-ioctl.c >>>>>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, >>>>>> unsigned long arg)> >>>>>> data.handle.handle = handle->id; >>>>>> >>>>>> break; >>>>>> >>>>>> } >>>>>> >>>>>> - case ION_IOC_SYNC: >>>>>> - { >>>>>> - ret = ion_sync_for_device(client, data.fd.fd); >>>>>> - break; >>>>>> - } >>>>> >>>>> You missed the case ION_IOC_SYNC: in compat_ion.c. >>>>> >>>>> While at it: Should we also remove the entire custom_ioctl infrastructure? >>>>> It's entirely unused afaict, and for a pure buffer allocator I don't see >>>>> any need to have custom ioctl. >>>> >>>> I second that, if you want to make ion a standard API, then we certainly don't >>>> want any custom ioctl. >>>> >>>>> More code to remove potentially: >>>>> - The entire compat ioctl stuff - would be an abi break, but I guess if we >>>>> pick the 32bit abi and clean up the uapi headers we'll be mostly fine. >>>>> would allow us to remove compat_ion.c entirely. >>>>> >>>>> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we >>>>> still need to be able to import anything. All the cache flushing/mapping >>>>> is done through dma-buf ops/ioctls. >>>>> >>>>> >>> >>> Good point to all of the above. I was considering keeping the import around >>> for backwards compatibility reasons but given how much other stuff is being >>> potentially broken, everything should just get ripped out. >> >> If you're ok with breaking the world, then I strongly suggest we go >> through the uapi header and replace all types with the standard >> fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all >> the compat ioctl code :-) > > I think the other comments from your "botching-up ioctls" [1] also apply ;-) > Namely - align structs to multiple of 64bit, add "flags" and properly > verity user input returning -EINVAL. > > -Emil > > [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Docume… I'm more torn on this. There's a difference between dropping an old ioctl/implicit caching vs. changing an actual ioctl ABI. Maybe having obvious breakage is better than subtle though, plus nobody has come begging me not to break the ABI yet. I might leave this for right before we do the actual move out of staging. Thanks, Laura

8 years, 8 months

Re: [Linaro-mm-sig] [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

by Daniel Vetter

On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote: > On Fri 03-03-17 09:37:55, Laura Abbott wrote: > > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > > On Thu 02-03-17 13:44:32, Laura Abbott wrote: > > >> Hi, > > >> > > >> There's been some recent discussions[1] about Ion-like frameworks. There's > > >> apparently interest in just keeping Ion since it works reasonablly well. > > >> This series does what should be the final clean ups for it to possibly be > > >> moved out of staging. > > >> > > >> This includes the following: > > >> - Some general clean up and removal of features that never got a lot of use > > >> as far as I can tell. > > >> - Fixing up the caching. This is the series I proposed back in December[2] > > >> but never heard any feedback on. It will certainly break existing > > >> applications that rely on the implicit caching. I'd rather make an effort > > >> to move to a model that isn't going directly against the establishement > > >> though. > > >> - Fixing up the platform support. The devicetree approach was never well > > >> recieved by DT maintainers. The proposal here is to think of Ion less as > > >> specifying requirements and more of a framework for exposing memory to > > >> userspace. > > >> - CMA allocations now happen without the need of a dummy device structure. > > >> This fixes a bunch of the reasons why I attempted to add devicetree > > >> support before. > > >> > > >> I've had problems getting feedback in the past so if I don't hear any major > > >> objections I'm going to send out with the RFC dropped to be picked up. > > >> The only reason there isn't a patch to come out of staging is to discuss any > > >> other changes to the ABI people might want. Once this comes out of staging, > > >> I really don't want to mess with the ABI. > > > > > > Could you recapitulate concerns preventing the code being merged > > > normally rather than through the staging tree and how they were > > > addressed? > > > > > > > Sorry, I'm really not understanding your question here, can you > > clarify? > > There must have been a reason why this code ended up in the staging > tree, right? So my question is what those reasons were and how they were > handled in order to move the code from the staging subtree. No one gave a thing about android in upstream, so Greg KH just dumped it all into staging/android/. We've discussed ION a bunch of times, recorded anything we'd like to fix in staging/android/TODO, and Laura's patch series here addresses a big chunk of that. This is pretty much the same approach we (gpu folks) used to de-stage the syncpt stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

8 years, 8 months

Re: [Linaro-mm-sig] [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

by Laura Abbott

On 03/03/2017 05:29 AM, Michal Hocko wrote: > On Thu 02-03-17 13:44:32, Laura Abbott wrote: >> Hi, >> >> There's been some recent discussions[1] about Ion-like frameworks. There's >> apparently interest in just keeping Ion since it works reasonablly well. >> This series does what should be the final clean ups for it to possibly be >> moved out of staging. >> >> This includes the following: >> - Some general clean up and removal of features that never got a lot of use >> as far as I can tell. >> - Fixing up the caching. This is the series I proposed back in December[2] >> but never heard any feedback on. It will certainly break existing >> applications that rely on the implicit caching. I'd rather make an effort >> to move to a model that isn't going directly against the establishement >> though. >> - Fixing up the platform support. The devicetree approach was never well >> recieved by DT maintainers. The proposal here is to think of Ion less as >> specifying requirements and more of a framework for exposing memory to >> userspace. >> - CMA allocations now happen without the need of a dummy device structure. >> This fixes a bunch of the reasons why I attempted to add devicetree >> support before. >> >> I've had problems getting feedback in the past so if I don't hear any major >> objections I'm going to send out with the RFC dropped to be picked up. >> The only reason there isn't a patch to come out of staging is to discuss any >> other changes to the ABI people might want. Once this comes out of staging, >> I really don't want to mess with the ABI. > > Could you recapitulate concerns preventing the code being merged > normally rather than through the staging tree and how they were > addressed? > Sorry, I'm really not understanding your question here, can you clarify? Thanks, Laura

8 years, 8 months

Re: [Linaro-mm-sig] [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE

by Laura Abbott

On 02/22/2017 05:01 PM, Chen Feng wrote: > > > On 2017/2/22 3:29, Laura Abbott wrote: >> On 02/20/2017 10:05 PM, Chen Feng wrote: >>> Hi Laura, >>> >>> When we enable kernel v4.4 or newer version on our platform, we meet the issue >>> of flushing cache without reference device. It seems that this patch set is >>> a solution. I'm curious the progress of the discussion. Do you have any plan >>> to fix it in v4.4 and newer kernel verison? >>> >> >> No, I've abandoned this approach based on feedback. The APIs had too much >> potential for incorrect usage. I'm ripping out the implicit caching in Ion >> and switching it to a model where there should always be a device available. >> >> What's your use case where you don't have a device structure? >> > Userspace use ioctl to flush cache for device. > > ion_sync_for_device > dma_sync_sg_for_device(NULL, buffer->sg_table->sgl, > buffer->sg_table->nents, DMA_BIDIRECTIONAL); > > And sys-heap when allocate a zero buffer flush zero data to ddr. > alloc_buffer_page > ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order, > DMA_BIDIRECTIONAL); > > Yes, those calls are being removed. This is what I proposed back in December https://marc.info/?l=linux-kernel&m=148176054902921&w=2 I never heard any feedback on it so I assume everyone was okay with the general direction. I plan on pushing a revised and expanded version of that series once the merge window closes. Thanks, Laura > >> Thanks, >> Laura >> >>> On 2016/9/14 2:41, Laura Abbott wrote: >>>> On 09/13/2016 08:14 AM, Will Deacon wrote: >>>>> On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote: >>>>>> On 09/13/2016 02:19 AM, Will Deacon wrote: >>>>>>> On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote: >>>>>>>> >>>>>>>> arm64 may need to guarantee the caches are synced. Implement versions of >>>>>>>> the kernel_force_cache API to allow this. >>>>>>>> >>>>>>>> Signed-off-by: Laura Abbott <labbott(a)redhat.com> >>>>>>>> --- >>>>>>>> v3: Switch to calling cache operations directly instead of relying on >>>>>>>> DMA mapping. >>>>>>>> --- >>>>>>>> arch/arm64/include/asm/cacheflush.h | 8 ++++++++ >>>>>>>> arch/arm64/mm/cache.S | 24 ++++++++++++++++++++---- >>>>>>>> arch/arm64/mm/flush.c | 11 +++++++++++ >>>>>>>> 3 files changed, 39 insertions(+), 4 deletions(-) >>>>>>> >>>>>>> I'm really hesitant to expose these cache routines as an API solely to >>>>>>> support a driver sitting in staging/. I appreciate that there's a chicken >>>>>>> and egg problem here, but we *really* don't want people using these routines >>>>>>> in preference to the DMA API, and I fear that we'll simply grow a bunch >>>>>>> more users of these things if we promote it as an API like you're proposing. >>>>>>> >>>>>>> Can the code not be contained under staging/, as part of ion? >>>>>>> >>>>>> >>>>>> I proposed that in V1 and it was suggested I make it a proper API >>>>>> >>>>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47654… >>>>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47672… >>>>> >>>>> :/ then I guess we're in disagreement. If ion really needs this stuff >>>>> (which I don't fully grok), perhaps we should be exposing something at >>>>> a higher level from the architecture, so it really can't be used for >>>>> anything other than ion. >>>> >>>> I talked/complained about this at a past plumbers. The gist is that Ion >>>> ends up acting as a fake DMA layer for clients. It doesn't match nicely >>>> because clients can allocate both coherent and non-coherent memory. >>>> Trying to use dma_map doesn't work because a) a device for coherency isn't >>>> known at allocation time b) it kills performance. Part of the motivation >>>> for taking this approach is to avoid the need to rework the existing >>>> Android userspace and keep the existing behavior, as terrible as it >>>> is. Having Ion out of staging and not actually usable isn't helpful. >>>> >>>> I'll give this all some more thought and hopefully have one or two more >>>> proposals before Connect/Plumbers. >>>> >>>>> >>>>> Will >>>>> >>>> >>>> Thanks, >>>> Laura >>>> _______________________________________________ >>>> Linaro-mm-sig mailing list >>>> Linaro-mm-sig(a)lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig >>> >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel(a)lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >> >> >> . >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >

8 years, 8 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: add support for compat ioctl

by Daniel Vetter

On Tue, Feb 21, 2017 at 4:08 PM, Christian König <deathsimple(a)vodafone.de> wrote: > Am 21.02.2017 um 15:55 schrieb Marek Szyprowski: >> >> Dear All, >> >> On 2017-02-21 15:37, Marek Szyprowski wrote: >>> >>> Hi Christian, >>> >>> On 2017-02-21 14:59, Christian König wrote: >>>> >>>> Am 21.02.2017 um 14:21 schrieb Marek Szyprowski: >>>>> >>>>> Add compat ioctl support to dma-buf. This lets one to use >>>>> DMA_BUF_IOCTL_SYNC >>>>> ioctl from 32bit application on 64bit kernel. Data structures for both >>>>> 32 >>>>> and 64bit modes are same, so there is no need for additional >>>>> translation >>>>> layer. >>>> >>>> >>>> Well I might be wrong, but IIRC compat_ioctl was just optional and if >>>> not specified unlocked_ioctl was called instead. >>>> >>>> If that is true your patch wouldn't have any effect at all. >>> >>> >>> Well, then why I got -ENOTTY in the 32bit test app for this ioctl on >>> 64bit ARM64 kernel without this patch? >>> >> >> I've checked in fs/compat_ioctl.c, I see no fallback in >> COMPAT_SYSCALL_DEFINE3, >> so one has to provide compat_ioctl callback to have ioctl working with >> 32bit >> apps. > > > Then my memory cheated on me. > > In this case the patch is Reviewed-by: Christian König > <christian.koenig(a)amd.com>. Since you have commit rights for drm-misc, care to push this to drm-misc-next-fixes pls? Also I think this warrants a cc: stable, clearly an obvious screw-up in creating this api on our side :( So feel free to smash my ack on the patch. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

8 years, 8 months

Re: [Linaro-mm-sig] [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE

by Laura Abbott

On 02/20/2017 10:05 PM, Chen Feng wrote: > Hi Laura, > > When we enable kernel v4.4 or newer version on our platform, we meet the issue > of flushing cache without reference device. It seems that this patch set is > a solution. I'm curious the progress of the discussion. Do you have any plan > to fix it in v4.4 and newer kernel verison? > No, I've abandoned this approach based on feedback. The APIs had too much potential for incorrect usage. I'm ripping out the implicit caching in Ion and switching it to a model where there should always be a device available. What's your use case where you don't have a device structure? Thanks, Laura > On 2016/9/14 2:41, Laura Abbott wrote: >> On 09/13/2016 08:14 AM, Will Deacon wrote: >>> On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote: >>>> On 09/13/2016 02:19 AM, Will Deacon wrote: >>>>> On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote: >>>>>> >>>>>> arm64 may need to guarantee the caches are synced. Implement versions of >>>>>> the kernel_force_cache API to allow this. >>>>>> >>>>>> Signed-off-by: Laura Abbott <labbott(a)redhat.com> >>>>>> --- >>>>>> v3: Switch to calling cache operations directly instead of relying on >>>>>> DMA mapping. >>>>>> --- >>>>>> arch/arm64/include/asm/cacheflush.h | 8 ++++++++ >>>>>> arch/arm64/mm/cache.S | 24 ++++++++++++++++++++---- >>>>>> arch/arm64/mm/flush.c | 11 +++++++++++ >>>>>> 3 files changed, 39 insertions(+), 4 deletions(-) >>>>> >>>>> I'm really hesitant to expose these cache routines as an API solely to >>>>> support a driver sitting in staging/. I appreciate that there's a chicken >>>>> and egg problem here, but we *really* don't want people using these routines >>>>> in preference to the DMA API, and I fear that we'll simply grow a bunch >>>>> more users of these things if we promote it as an API like you're proposing. >>>>> >>>>> Can the code not be contained under staging/, as part of ion? >>>>> >>>> >>>> I proposed that in V1 and it was suggested I make it a proper API >>>> >>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47654… >>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47672… >>> >>> :/ then I guess we're in disagreement. If ion really needs this stuff >>> (which I don't fully grok), perhaps we should be exposing something at >>> a higher level from the architecture, so it really can't be used for >>> anything other than ion. >> >> I talked/complained about this at a past plumbers. The gist is that Ion >> ends up acting as a fake DMA layer for clients. It doesn't match nicely >> because clients can allocate both coherent and non-coherent memory. >> Trying to use dma_map doesn't work because a) a device for coherency isn't >> known at allocation time b) it kills performance. Part of the motivation >> for taking this approach is to avoid the need to rework the existing >> Android userspace and keep the existing behavior, as terrible as it >> is. Having Ion out of staging and not actually usable isn't helpful. >> >> I'll give this all some more thought and hopefully have one or two more >> proposals before Connect/Plumbers. >> >>> >>> Will >>> >> >> Thanks, >> Laura >> _______________________________________________ >> Linaro-mm-sig mailing list >> Linaro-mm-sig(a)lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >

8 years, 8 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: add support for compat ioctl

by Marek Szyprowski

Hi Christian, On 2017-02-21 14:59, Christian König wrote: > Am 21.02.2017 um 14:21 schrieb Marek Szyprowski: >> Add compat ioctl support to dma-buf. This lets one to use >> DMA_BUF_IOCTL_SYNC >> ioctl from 32bit application on 64bit kernel. Data structures for >> both 32 >> and 64bit modes are same, so there is no need for additional translation >> layer. > > Well I might be wrong, but IIRC compat_ioctl was just optional and if > not specified unlocked_ioctl was called instead. > > If that is true your patch wouldn't have any effect at all. Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 64bit ARM64 kernel without this patch? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

8 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig