| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Most users of this interface just want to use it with the default
GFP_KERNEL flags, but for cases where DMA memory is allocated it may be
called from a different context.
No functional change yet, just passing through the flag to the
underlying alloc_contig_range function.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Lucas Stach <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Cc: Radim Krcmar <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Chris Zankel <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Alexander Graf <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The header uses types and definitions from the linux/init.h as well as
linux/types.h headers without explicitly including them. This causes a
failure to compile if they are not implicitly pulled in by includers.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This was found during userspace fuzzing test when a large size dma cma
allocation is made by driver(like ion) through userspace.
show_stack+0x10/0x1c
dump_stack+0x74/0xc8
kasan_report_error+0x2b0/0x408
kasan_report+0x34/0x40
__asan_storeN+0x15c/0x168
memset+0x20/0x44
__dma_alloc_coherent+0x114/0x18c
Signed-off-by: Rohit Vaswani <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Cc: Marek Szyprowski <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Constify function parameters and use correct signness where needed.
Signed-off-by: Sasha Levin <[email protected]>
Cc: Michal Nazarewicz <[email protected]>
Cc: Marek Szyprowski <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Acked-by: Gregory Fong <[email protected]>
Cc: Pintu Kumar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
When the system boots up, in the dmesg logs we can see the memory
statistics along with total reserved as below. Memory: 458840k/458840k
available, 65448k reserved, 0K highmem
When CMA is enabled, still the total reserved memory remains the same.
However, the CMA memory is not considered as reserved. But, when we see
/proc/meminfo, the CMA memory is part of free memory. This creates
confusion. This patch corrects the problem by properly subtracting the
CMA reserved memory from the total reserved memory in dmesg logs.
Below is the dmesg snapshot from an arm based device with 512MB RAM and
12MB single CMA region.
Before this change:
Memory: 458840k/458840k available, 65448k reserved, 0K highmem
After this change:
Memory: 458840k/458840k available, 53160k reserved, 12288k cma-reserved, 0K highmem
Signed-off-by: Pintu Kumar <[email protected]>
Signed-off-by: Vishnu Pratap Singh <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
Cc: Rafael Aquini <[email protected]>
Cc: Jerome Marchand <[email protected]>
Cc: Marek Szyprowski <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
In the current code, the base and size parameters order is not consistent
in functions declaration and definition. If someone calls these functions
according to the declaration parameters order in cma.h, he will run into
some bug and it's hard to find the reason.
This patch makes the parameters order consistent in functions declaration
and definition.
Signed-off-by: Weijie Yang <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
Signed-off-by: Marek Szyprowski <[email protected]>
|
|
Add a function to create CMA region from previously reserved memory and
add support for handling 'shared-dma-pool' reserved-memory device tree
nodes.
Based on previous code provided by Josh Cartwright <[email protected]>
Signed-off-by: Marek Szyprowski <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Michal Nazarewicz <[email protected]>
Cc: Grant Likely <[email protected]>
Cc: Laura Abbott <[email protected]>
Cc: Josh Cartwright <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Kyungmin Park <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Conventionally, we put output param to the end of param list and put the
'base' ahead of 'size', but cma_declare_contiguous() doesn't look like
that, so change it.
Additionally, move down cma_areas reference code to the position where
it is really needed.
Signed-off-by: Joonsoo Kim <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
Reviewed-by: Aneesh Kumar K.V <[email protected]>
Cc: Alexander Graf <[email protected]>
Cc: Aneesh Kumar K.V <[email protected]>
Cc: Gleb Natapov <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Zhang Yanfei <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Paul Mackerras <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the KVM on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar. From my
guess, it is caused by some needs on bitmap management. KVM side wants
to maintain bitmap not for 1 page, but for more size. Eventually it use
bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through this
patch.
This change could also help developer who want to use CMA in their new
feature development, since they can use CMA easily without copying &
pasting this reserved area management code.
In previous patches, we have prepared some features to generalize CMA
reserved area management and now it's time to do it. This patch moves
core functions to mm/cma.c and change DMA APIs to use these functions.
There is no functional change in DMA APIs.
Signed-off-by: Joonsoo Kim <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
Acked-by: Zhang Yanfei <[email protected]>
Acked-by: Minchan Kim <[email protected]>
Reviewed-by: Aneesh Kumar K.V <[email protected]>
Cc: Alexander Graf <[email protected]>
Cc: Aneesh Kumar K.V <[email protected]>
Cc: Gleb Natapov <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Paul Mackerras <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|