, just drop the in-kernel
copy of the ion code now, as it's not used, and is only causing problems
for everyone involved.
Cc: "Arve Hjønnevåg"
Cc: "Christian König"
Cc: Christian Brauner
Cc: Christoph Hellwig
Cc: Hridya Valsaraju
Cc: Joel Fernandes
Cc: John Stultz
Cc:
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/staging/android/ion/ion.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/st
On 9/29/19 3:28 AM, jun.zh...@intel.com wrote:
From: zhang jun
we see tons of warning like:
[ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
write-combining for [mem 0x1e7a8-0x1e7a87fff], got write-back
[ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
wri
On 8/26/19 3:55 AM, Alexey Skidanov wrote:
On 8/26/19 11:36 AM, Laura Abbott wrote:
On 8/23/19 10:28 PM, Alexey Skidanov wrote:
In ion_cma_heap, the allocated buffer is represented by a single
struct scatterlist instance. The length field of this struct is
32 bit, hence the maximal size of
On 8/23/19 10:28 PM, Alexey Skidanov wrote:
In ion_cma_heap, the allocated buffer is represented by a single
struct scatterlist instance. The length field of this struct is
32 bit, hence the maximal size of requested buffer should be
less than 4GB.
The len paramer of the allocation function is 6
On 7/17/19 12:31 PM, Alexander Popov wrote:
Hello!
The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION Memory
Allocator.
Syzkaller uses several methods [2] to limit memory consumption of the userspace
processes calling the syscalls for testing the kernel:
- setrlimit(),
-
sting buffers
- * @buffer_lock: lock protecting the tree of buffers
* @lock: rwsem protecting the tree of heaps and clients
*/
struct ion_device {
struct miscdevice dev;
- struct rb_root buffers;
- struct mutex buffer_lock;
struct rw_semaphore
On 7/3/19 4:18 AM, Nishka Dasgupta wrote:
Remove file ion_chunk_heap.c as its functions and definitions are not
used anywhere else.
Issue found with Coccinelle.
Acked-by: Laura Abbott
Signed-off-by: Nishka Dasgupta
---
drivers/staging/android/ion/Kconfig | 9 --
drivers
hink we're at the point where nobody wants the
carveout and chunk heaps so I'd actually be okay with removing
those files. Just to be explicit:
Acked-by: Laura Abbott
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 3/29/19 7:26 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, March 29, 2019 9:27 PM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 3/29/19 11:40 AM, Zeng Tao wrote:
There are two reasons for this patch:
1. There are some potential requirements for ion_alloc in kernel space,
some media drivers need to allocate media buffers from ion instead of
buddy or dma framework, this is more convient and clean very for media
drivers.
On 3/20/19 7:23 AM, Vlastimil Babka wrote:
You should have CC'd the ION maintainers/lists per
./scripts/get_maintainer.pl - CCing now.
On 3/14/19 12:06 PM, Zhaoyang Huang wrote:
From: Zhaoyang Huang
Two action for this patch:
1. set a batch size for system heap's shrinker, which can have it b
On 1/24/19 8:44 AM, Brian Starkey wrote:
On Thu, Jan 24, 2019 at 10:04:46AM -0600, Andrew F. Davis wrote:
On 1/23/19 11:11 AM, Brian Starkey wrote:
[snip]
I'm very new to all this, so any pointers to history in this area are
appreciated.
[snip]
In case you didn't come across it alrea
(i = 0; i < NUM_ORDERS; i++) {
struct ion_page_pool *pool;
+ gfp_t gfp_flags = low_order_gfp_flags;
if (orders[i] > 4)
gfp_flags = high_order_gfp_flags;
Acked-by: Laura Abbott
___
devel
On 2/15/19 11:01 AM, John Stultz wrote:
On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
[snip]
Some thoughts, as this ABI break has the potential to be pretty painful.
1) Unfortunately, this ABI is exposed *throu
On 2/11/19 11:09 PM, Jing Xia wrote:
gfp_flags is always set high_order_gfp_flags even if allocations of
order 0 are made.But for smaller allocations, the system should be able
to reclaim some memory.
Signed-off-by: Jing Xia
Reviewed-by: Yuming Han
Reviewed-by: Zhaoyang Huang
Reviewed-by: Ors
On 1/19/19 2:25 AM, Christoph Hellwig wrote:
On Fri, Jan 18, 2019 at 10:37:46AM -0800, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
And who is going
On 1/18/19 1:32 PM, Liam Mark wrote:
On Fri, 18 Jan 2019, Laura Abbott wrote:
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
On 1/18/19 12:43 PM, Andrew F. Davis wrote:
On 1/18/19 2:31 PM, Laura Abbott wrote:
On 1/17/19 8:13 AM, Andrew F. Davis wrote:
On 1/16/19 4:48 PM, Liam Mark wrote:
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
On 1/15/19 1:05 PM, Laura Abbott wrote:
On 1/15/19 10:38 AM, Andrew F. Davis wrote
ttachment->priv;
struct ion_buffer *buffer = dmabuf->priv;
- free_duped_table(a->table);
mutex_lock(&buffer->lock);
list_del(&a->list);
mutex_unlock(&buffer->lock);
+ free_duped_table(a->table)
On 1/17/19 8:13 AM, Andrew F. Davis wrote:
On 1/16/19 4:48 PM, Liam Mark wrote:
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
On 1/15/19 1:05 PM, Laura Abbott wrote:
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote
On 1/16/19 8:05 AM, Andrew F. Davis wrote:
On 1/15/19 12:58 PM, Laura Abbott wrote:
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
On 1/18/19 1:59 AM, Greg Kroah-Hartman wrote:
On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
When enabled the helpers functions for creating carveout and chunk heaps
should have declarations in the ION header.
Why? No one calls these from what I can tell.
Which makes me bel
On 1/16/19 9:12 AM, Andrew F. Davis wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
The heap name can be used for debugging but otherwise does not seem
to be required and no other part of the code will fail if left NUL
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable b
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses fro
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firew
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself with the framework to help in whatever way I
can in getting all this up to the standard
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
bac
On 1/2/19 10:28 PM, Alexey Skidanov wrote:
On 1/3/19 12:37 AM, Laura Abbott wrote:
On 12/20/18 1:29 PM, Alexey Skidanov wrote:
On 12/20/18 10:36 PM, Laura Abbott wrote:
On 12/16/18 2:46 AM, Alexey Skidanov wrote:
Chunk heap instantiation should be supported for device tree platforms
and
On 1/3/19 5:42 PM, Zengtao (B) wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Thursday, January 03, 2019 6:31 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes ;
de
On 12/20/18 1:29 PM, Alexey Skidanov wrote:
On 12/20/18 10:36 PM, Laura Abbott wrote:
On 12/16/18 2:46 AM, Alexey Skidanov wrote:
Chunk heap instantiation should be supported for device tree platforms
and
non device tree platforms. For device tree platforms, it's a platform
specific
On 12/24/18 12:19 AM, Qing Xia wrote:
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buffer's map_kernel, it's not necessary. And
On 12/23/18 6:47 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, December 21, 2018 4:50 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 12/19/18 5:39 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Thursday, December 20, 2018 2:10 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 12/16/18 2:46 AM, Alexey Skidanov wrote:
Chunk heap instantiation should be supported for device tree platforms and
non device tree platforms. For device tree platforms, it's a platform
specific code responsibility to retrieve the heap configuration data
and to call the appropriate API for hea
On 12/19/18 9:19 AM, Zeng Tao wrote:
In some usecases, the buffer cached attribute is not determined at
allocation time, it's determined just before the real cpu mapping.
And from the memory view of point, a buffer should not have the cached
attribute util is really mapped by the cpu. So in this
On 11/30/18 6:43 AM, Yangtao Li wrote:
seq_file.h does not need to be included,so remove it.
Acked-by: Laura Abbott
Signed-off-by: Yangtao Li
---
drivers/staging/android/ion/ion.c | 1 -
drivers/staging/android/ion/ion_system_heap.c | 1 -
2 files changed, 2 deletions
On 11/27/18 12:07 PM, Alexey Skidanov wrote:
On 11/27/18 9:20 PM, Laura Abbott wrote:
On 11/26/18 10:43 AM, Alexey Skidanov wrote:
On 11/26/18 6:39 PM, Laura Abbott wrote:
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey
On 11/26/18 10:43 AM, Alexey Skidanov wrote:
On 11/26/18 6:39 PM, Laura Abbott wrote:
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM, Alexey Skidanov wrote:
Create chunk heap of specified size and base address by adding
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM, Alexey Skidanov wrote:
Create chunk heap of specified size and base address by adding
"ion_chunk_heap=size@start" kernel boot parameter.
Signed-off-by: Alexey Skidanov
---
On 11/11/18 11:29 AM, Alexey Skidanov wrote:
Create chunk heap of specified size and base address by adding
"ion_chunk_heap=size@start" kernel boot parameter.
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion_chunk_heap.c | 40
1 file changed, 40
On 11/8/18 11:34 AM, Alexey Skidanov wrote:
On 11/8/18 9:15 PM, Laura Abbott wrote:
On 10/22/18 2:15 PM, Alexey Skidanov wrote:
Heap name is mundatory.
I'm wary of this and the other change because it misses the
broader problem of dealing with the carveout heaps.
I still want to r
On 10/22/18 2:15 PM, Alexey Skidanov wrote:
Heap name is mundatory.
I'm wary of this and the other change because it misses the
broader problem of dealing with the carveout heaps.
I still want to remove the carveout and chunk heap. I get
that it's being used for out of tree work but at this po
;
- the number of allocated bytes watermark.
Acked-by: Laura Abbott
Signed-off-by: Alexey Skidanov
---
v3:
Removed debugfs_create_dir() return value checking
v4:
Added spinlock to protect heap statistics
v5:
Rebased on staging-next
drivers/staging/android/ion/ion.c
On 10/22/2018 07:02 AM, Alexey Skidanov wrote:
The heap name might be uninitialized and access might crash the
kernel.
The heap name should never be null so this seems like this is being
fixed in the wrong place. Can you explain more how you are hitting
this issue?
Thanks,
Laura
Signed-off-
On 10/11/2018 03:44 AM, Rock Lee wrote:
On Thu, Oct 11, 2018 at 4:12 PM Dan Carpenter wrote:
On Thu, Oct 11, 2018 at 11:24:49AM +0800, Rock Lee wrote:
Hi
I tested direct io with a ion allocated buffer, got a -EFAULT
error. It turned out that ion_mmap() set VM_IO & VM_PFNMAP, but
check_vm
On 10/03/2018 01:03 PM, Alexey Skidanov wrote:
On 10/03/2018 09:07 PM, Laura Abbott wrote:
On 10/02/2018 07:27 AM, Alexey Skidanov wrote:
Hi,
Sometimes HW requires memory buffer to be aligned in order to be used
properly. Of course, we may overcome the lack of aligned allocation
support
On 10/02/2018 07:27 AM, Alexey Skidanov wrote:
Hi,
Sometimes HW requires memory buffer to be aligned in order to be used
properly. Of course, we may overcome the lack of aligned allocation
support, but we may easily add it because CMA and gen_pool (used by
several heaps) already support it.
Do
;
- the number of allocated bytes watermark.
If none of the other Android people have strong opinions
Acked-by: Laura Abbott
Signed-off-by: Alexey Skidanov
---
v3:
Removed debugfs_create_dir() return value checking
v4:
Added spinlock to protect heap statistics
drivers
On 09/11/2018 04:29 AM, Alexey Skidanov wrote:
Heap statistics have been removed and currently even basics statistics
are missing.
This patch creates per heap debugfs directory /sys/kernel/debug/
and adds the following counters:
- the number of allocated buffers;
- the number of allocated bytes;
On 09/18/2018 10:50 AM, Greg KH wrote:
On Tue, Sep 11, 2018 at 02:29:19PM +0300, Alexey Skidanov wrote:
Heap statistics have been removed and currently even basics statistics
are missing.
This patch creates per heap debugfs directory /sys/kernel/debug/
and adds the following counters:
- the num
On 09/10/2018 03:00 AM, Alexey Skidanov wrote:
On 09/10/2018 12:36 PM, Dan Carpenter wrote:
On Sun, Sep 09, 2018 at 01:44:31AM +0300, Alexey Skidanov wrote:
The heap statistics have been removed and currently even basics statistics
are missing.
Remind me why did we remove them? What was th
On 09/07/2018 08:20 AM, jun qian wrote:
The value in the wrong position will cause misunderstanding,
when the debug infomations display in the window.
I think the existing order is okay, it's just not separated
well. It's "$count pages of order $order". I also just acked a
patch to remove all
On 09/04/2018 10:03 PM, Alexey Skidanov wrote:
ION had supported heap debug info under /sys/kernel/debug/ion/.
This support have been removed but some leftovers (dead code) still exist.
This patch removes the existing dead code.
Acked-by: Laura Abbott
Fixes: 15c6098cfec5 ("st
ly no way to use it
safely.
This patch is applied on top of 4.4.y, and applies to older kernels
too. 4.9.y was fixed separately. Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.
Acked-by: Laura Abbott
Cc: sta...@vger.kernel.or
("staging: android: ion: Remove ion_handle and ion_client")) specified
somewhere in the commit text so if you add that, you can add
Acked-by: Laura Abbott
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion.h | 5 -
drivers/staging/android/ion/io
: Laura Abbott
---
drivers/staging/android/ion/ion_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_heap.c
b/drivers/staging/android/ion/ion_heap.c
index 772dad65396e..f32c12439eee 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b
: syzbot
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e74db7902549..a68329411b29 100644
--- a/drivers/staging/android/ion/ion.c
+++ b
On 05/09/2018 11:59 PM, Dmitry Vyukov wrote:
On Wed, Jan 10, 2018 at 7:14 PM, Laura Abbott wrote:
On 01/09/2018 02:58 PM, syzbot wrote:
Hello,
syzkaller hit the following crash on
06d41862286aa7bc634a1dd9e6e7e96f925ef30a
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
On 05/07/2018 07:51 AM, Nathan Chancellor wrote:
On Mon, May 07, 2018 at 06:46:23AM -0700, Laura Abbott wrote:
On 05/06/2018 06:43 PM, Nathan Chancellor wrote:
Hi everyone,
I compiled the ion driver with W=1 where I encountered the two following
warnings and I had a couple of questions about
On 05/07/2018 07:40 AM, Nathan Chancellor wrote:
On Mon, May 07, 2018 at 06:37:52AM -0700, Laura Abbott wrote:
On 05/06/2018 06:18 PM, Nathan Chancellor wrote:
checkpatch.pl complains these are invalid because the rules in
Documentation/process/license-rules.rst state that C headers should
On 05/06/2018 06:43 PM, Nathan Chancellor wrote:
Hi everyone,
I compiled the ion driver with W=1 where I encountered the two following
warnings and I had a couple of questions about solving them.
1.
drivers/staging/android/ion/ion.c: In function ‘ion_dma_buf_begin_cpu_access’:
drivers/staging
ex_init(&buffer->lock);
mutex_lock(&dev->buffer_lock);
Acked-by: Laura Abbott
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 05/06/2018 06:18 PM, Nathan Chancellor wrote:
checkpatch.pl complains these are invalid because the rules in
Documentation/process/license-rules.rst state that C headers should
have "/* */" style comments.
The SPDX markings are special, but I don't see anything from a
quick read of the SPDX
On 04/27/2018 02:29 AM, vji...@codeaurora.org wrote:
On 2018-04-27 10:40, vji...@codeaurora.org wrote:
On 2018-04-25 21:17, Laura Abbott wrote:
On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
An issue is observed where mallocs are failing due to overcommit
On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
An issue is observed where mallocs are failing due to overcommit failure.
The failure happens when there is high ION page pool since ION page
pool is not considered reclaimable by the overcommit calculation code.
This c
ixups should be
small these days.
Acked-by: Laura Abbott
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
Cc: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
---
MAINTAINER
e that can be shared between drivers.
If you're not using Android its probably safe to
The formatting here looks a little funny, did you manually edit the
patch to take out the diff-stat and index? The patch seem to apply
okay, so I'm just curious. Eithe
On 03/08/2018 04:45 PM, Liam Mark wrote:
On Wed, 7 Mar 2018, Laura Abbott wrote:
On 02/28/2018 09:18 PM, Liam Mark wrote:
The issue:
Currently in ION if you allocate uncached memory it is possible that there
are still dirty lines in the cache. And often these dirty lines in the
cache are
On 02/28/2018 09:18 PM, Liam Mark wrote:
The issue:
Currently in ION if you allocate uncached memory it is possible that there
are still dirty lines in the cache. And often these dirty lines in the
cache are the zeros which were meant to clear out any sensitive kernel
data.
What this means is
On 02/26/2018 09:07 AM, Shuah Khan wrote:
On 02/19/2018 11:33 AM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
On 02/19/2018 07:31 AM, Daniel Vetter wrote:
On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
Ion is designed to be a framework
There's no need to print messages each time we alloc and free. Remove them.
Signed-off-by: Laura Abbott
---
v2: No changes
---
tools/testing/selftests/android/ion/ionutils.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/testing/selftests/android/ion/ionutils.c
b/tools/te
Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.
Reviewed-by: Daniel Vetter
Signed-off-by: Laura Abbott
er to actually make some of the dma_buf calls. The vgem
DRM driver exists mostly for testing and works great for this case.
Changes since v1:
- Dropped RFC
- Feedback/review from Daniel Vetter about DRM ioctls
Thanks,
Laura
Laura Abbott (2):
selftests: ion: Remove some prints
selftests: ion
On 02/19/2018 07:31 AM, Daniel Vetter wrote:
On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls
On 02/16/2018 04:17 AM, Alexey Skidanov wrote:
On 02/16/2018 01:48 AM, Laura Abbott wrote:
On 02/12/2018 02:33 PM, Alexey Skidanov wrote:
Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space.
On 32-bit platforms, vmap
l comments.
Thanks,
Laura
Laura Abbott (2):
selftests: ion: Remove some prints
selftests: ion: Add simple test with the vgem driver
tools/testing/selftests/android/ion/Makefile | 3 +-
tools/testing/selftests/android/ion/config| 1 +
tools/testing/selftests/android/ion/ion
Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.
Signed-off-by: Laura Abbott
---
tools/testing
There's no need to print messages each time we alloc and free. Remove them.
Signed-off-by: Laura Abbott
---
tools/testing/selftests/android/ion/ionutils.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/testing/selftests/android/ion/ionutils.c
b/tools/testing/selftests/an
On 02/12/2018 02:33 PM, Alexey Skidanov wrote:
Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space.
On 32-bit platforms, vmap() might fail on large enough buffers due to the
limited available vmalloc space. dma_buf_kmap() sh
On 02/12/2018 01:25 PM, Liam Mark wrote:
On Mon, 12 Feb 2018, Dan Carpenter wrote:
On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
Fix the dup_sg_table function to initialize the dma_address of the new
sg list entries instead of the source dma_address entries.
Fixes: 17fd283f3870
On 02/12/2018 11:24 PM, Alexey Skidanov wrote:
Hello,
Correct me if I'm wrong, but there is no user space interface, similar
to the dma_buf_start_cpu_access()/dma_buf_end_cpu_access() to handle IO
coherency. That is, on the platforms, where the SW is responsible for IO
coherency handling, the fo
On 02/12/2018 12:22 PM, Alexey Skidanov wrote:
On 02/12/2018 09:52 PM, Laura Abbott wrote:
On 02/12/2018 11:11 AM, Alexey Skidanov wrote:
On 02/12/2018 08:42 PM, Laura Abbott wrote:
On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
Current ion defined allocation ioctl doesn't all
On 02/09/2018 10:21 PM, Liam Mark wrote:
The ION begin_cpu_access and end_cpu_access functions use the
dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
maintenance.
Currently it is possible to apply cache maintenance, via the
begin_cpu_access and end_cpu_access APIs, to ION b
On 02/09/2018 10:21 PM, Liam Mark wrote:
The ION begin_cpu_access and end_cpu_access functions use the
dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
maintenance.
Currently it is possible to apply cache maintenance, via the
begin_cpu_access and end_cpu_access APIs, to ION b
On 02/12/2018 11:21 AM, Alexey Skidanov wrote:
On 02/12/2018 08:30 PM, Laura Abbott wrote:
On 02/10/2018 01:43 AM, Alexey Skidanov wrote:
Hi,
Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space. On 32 bit
platforms
On 02/12/2018 11:11 AM, Alexey Skidanov wrote:
On 02/12/2018 08:42 PM, Laura Abbott wrote:
On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
Current ion defined allocation ioctl doesn't allow to specify the
requested
allocation alignment. CMA heap allocates buffers aligned on buffer size
On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
Current ion defined allocation ioctl doesn't allow to specify the requested
allocation alignment. CMA heap allocates buffers aligned on buffer size
page order.
Sometimes, the alignment requirement is less restrictive. In such cases,
providing specif
On 02/10/2018 01:43 AM, Alexey Skidanov wrote:
Hi,
Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space. On 32 bit
platforms, vmap() might fail on large enough buffers due to the limited
available vmalloc space.
dma_buf_kmap
On 02/07/2018 07:10 AM, Alexey Skidanov wrote:
On 02/07/2018 04:58 PM, Laura Abbott wrote:
On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
Yup, you've hit upon a key problem. Having fallbacks be stable
was always a problem and the recommendation these days is to
not rely on them. Yo
On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
Yup, you've hit upon a key problem. Having fallbacks be stable
was always a problem and the recommendation these days is to
not rely on them. You can specify a heap at a time and fallback
manually if you want that behavior.
If you have a proposal
On 01/31/2018 10:10 PM, Alexey Skidanov wrote:
On 01/31/2018 03:00 PM, Greg KH wrote:
On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote:
Any driver may access shared buffers, created by ion, using dma_buf_vmap and
dma_buf_vunmap dma-buf API that maps/unmaps previosuly allocated b
On 01/28/2018 08:24 AM, Alexey Skidanov wrote:
Hi,
According to my understanding, the allocation fall back order
completely depends on heap->id that is assigned during the heap
creation:
plist_for_each_entry(heap, &dev->heaps, node) {
/* if the caller didn't specify this heap id */
On 02/06/2018 03:10 PM, Laura Abbott wrote:
On 02/04/2018 07:26 PM, Yisheng Xie wrote:
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Ca
On 02/04/2018 07:26 PM, Yisheng Xie wrote:
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Can you clean up ion_page_pool_add to be a void return as
On 02/01/2018 04:34 AM, Yisheng Xie wrote:
When failed to create debug_root, we will go on initail other part of
ion, so we can just info this message to user and do not need a lable
to jump.
Acked-by: Laura Abbott
Signed-off-by: Yisheng Xie
---
drivers/staging/android/ion/ion.c | 5
1 - 100 of 399 matches
Mail list logo
