linux-toradex.git/kernel/dma/remap.c, branch v6.19

dma-remap: drop nth_page() in dma_common_contiguous_remap()

2025-09-21T21:22:06+00:00

dma_common_contiguous_remap() is used to remap an "allocated contiguous
region".  Within a single allocation, there is no need to use nth_page()
anymore.

Neither the buddy, nor hugetlb, nor CMA will hand out problematic page
ranges.

Link: https://lkml.kernel.org/r/20250901150359.867252-24-david@redhat.com
Signed-off-by: David Hildenbrand 
Acked-by: Marek Szyprowski 
Reviewed-by: Lorenzo Stoakes 
Cc: Robin Murphy 
Signed-off-by: Andrew Morton

dma-mapping: use bit masking to check VM_DMA_COHERENT

2024-08-22T04:15:35+00:00

In dma_common_find_pages(), area->flags are compared directly with
VM_DMA_COHERENT. This works because VM_DMA_COHERENT is the only set
flag.

During development of a new feature (ASI [1]), a new VM flag is
introduced, and that flag can be injected into VM_DMA_COHERENT mappings
(among others).  The presence of that flag caused
dma_common_find_pages() to return NULL for VM_DMA_COHERENT addresses,
leading to a lot of problems ending in crashing during boot. It took a
bit of time to figure this problem out.

It was a mistake to inject a VM flag to begin with, but it took a
significant amount of debugging to figure out the problem. Most users of
area->flags use bitmasking rather than equivalency to check for flags.
Update dma_common_find_pages() and dma_common_free_remap() to do the
same, which would have avoided the boot crashing. Instead, add a warning
in dma_common_find_pages() if any extra VM flags are set to catch such
problems more easily during development.

No functional change intended.

[1]https://lore.kernel.org/lkml/20240712-asi-rfc-24-v1-0-144b319a40d8@google.com/

Signed-off-by: Yosry Ahmed 
Signed-off-by: Christoph Hellwig

dma-remap: use kvmalloc_array/kvfree for larger dma memory remap

2023-06-07T13:06:28+00:00

If dma_direct_alloc() alloc memory in size of 64MB, the inner function
dma_common_contiguous_remap() will allocate 128KB memory by invoking
the function kmalloc_array(). and the kmalloc_array seems to fail to try to
allocate 128KB mem.

Call trace:
[14977.928623] qcrosvm: page allocation failure: order:5, mode:0x40cc0
[14977.928638] dump_backtrace.cfi_jt+0x0/0x8
[14977.928647] dump_stack_lvl+0x80/0xb8
[14977.928652] warn_alloc+0x164/0x200
[14977.928657] __alloc_pages_slowpath+0x9f0/0xb4c
[14977.928660] __alloc_pages+0x21c/0x39c
[14977.928662] kmalloc_order+0x48/0x108
[14977.928666] kmalloc_order_trace+0x34/0x154
[14977.928668] __kmalloc+0x548/0x7e4
[14977.928673] dma_direct_alloc+0x11c/0x4f8
[14977.928678] dma_alloc_attrs+0xf4/0x138
[14977.928680] gh_vm_ioctl_set_fw_name+0x3c4/0x610 [gunyah]
[14977.928698] gh_vm_ioctl+0x90/0x14c [gunyah]
[14977.928705] __arm64_sys_ioctl+0x184/0x210

work around by doing kvmalloc_array instead.

Signed-off-by: Gao Xu 
Reviewed-by: Suren Baghdasaryan 
Signed-off-by: Christoph Hellwig

kernel/dma: remove unnecessary unmap_kernel_range

2021-04-30T18:20:40+00:00

vunmap will remove ptes.

Link: https://lkml.kernel.org/r/20210322021806.892164-3-npiggin@gmail.com
Signed-off-by: Nicholas Piggin 
Reviewed-by: Christoph Hellwig 
Cc: Cédric Le Goater 
Cc: Uladzislau Rezki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dma-mapping: move more functions to dma-map-ops.h

2020-10-20T08:41:07+00:00

Due to a mismerge a bunch of prototypes that should have moved to
dma-map-ops.h are still in dma-mapping.h, fix that up.

Signed-off-by: Christoph Hellwig

dma-remap: align the size in dma_common_*_remap()

2020-06-23T12:14:41+00:00

Running a guest with a virtio-iommu protecting virtio devices
is broken since commit 515e5b6d90d4 ("dma-mapping: use vmap insted
of reimplementing it"). Before the conversion, the size was
page aligned in __get_vm_area_node(). Doing so fixes the
regression.

Fixes: 515e5b6d90d4 ("dma-mapping: use vmap insted of reimplementing it")
Signed-off-by: Eric Auger 
Signed-off-by: Christoph Hellwig

Merge tag 'dma-mapping-5.8' of git://git.infradead.org/users/hch/dma-mapping

2020-06-06T18:43:23+00:00

Pull dma-mapping updates from Christoph Hellwig:

 - enhance the dma pool to allow atomic allocation on x86 with AMD SEV
   (David Rientjes)

 - two small cleanups (Jason Yan and Peter Collingbourne)

* tag 'dma-mapping-5.8' of git://git.infradead.org/users/hch/dma-mapping:
  dma-contiguous: fix comment for dma_release_from_contiguous
  dma-pool: scale the default DMA coherent pool size with memory capacity
  x86/mm: unencrypted non-blocking DMA allocations use coherent pools
  dma-pool: add pool sizes to debugfs
  dma-direct: atomic allocations must come from atomic coherent pools
  dma-pool: dynamically expanding atomic pools
  dma-pool: add additional coherent pools to map to gfp mask
  dma-remap: separate DMA atomic pools from direct remap code
  dma-debug: make __dma_entry_alloc_check_leak() static

dma-mapping: use vmap insted of reimplementing it

2020-06-02T17:59:10+00:00

Replace the open coded instance of vmap with the actual function.  In
the non-contiguous (IOMMU) case this requires an extra find_vm_area,
but given that this isn't a fast path function that is a small price
to pay.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Acked-by: Peter Zijlstra (Intel) 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Gao Xiang 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Johannes Weiner 
Cc: "K. Y. Srinivasan" 
Cc: Laura Abbott 
Cc: Mark Rutland 
Cc: Michael Kelley 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Robin Murphy 
Cc: Sakari Ailus 
Cc: Stephen Hemminger 
Cc: Sumit Semwal 
Cc: Wei Liu 
Cc: Benjamin Herrenschmidt 
Cc: Catalin Marinas 
Cc: Heiko Carstens 
Cc: Paul Mackerras 
Cc: Vasily Gorbik 
Cc: Will Deacon 
Link: http://lkml.kernel.org/r/20200414131348.444715-6-hch@lst.de
Signed-off-by: Linus Torvalds

dma-remap: separate DMA atomic pools from direct remap code

2020-04-20T10:08:45+00:00

DMA atomic pools will be needed beyond only CONFIG_DMA_DIRECT_REMAP so
separate them out into their own file.

This also adds a new Kconfig option that can be subsequently used for
options, such as CONFIG_AMD_MEM_ENCRYPT, that will utilize the coherent
pools but do not have a dependency on direct remapping.

For this patch alone, there is no functional change introduced.

Reviewed-by: Christoph Hellwig 
Signed-off-by: David Rientjes 
[hch: fixup copyrights and remove unused includes]
Signed-off-by: Christoph Hellwig

lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr

2019-12-05T03:44:13+00:00

Follow the kernel conventions, rename addr_in_gen_pool to
gen_pool_has_addr.

[sjhuang@iluvatar.ai: fix Documentation/ too]
 Link: http://lkml.kernel.org/r/20181229015914.5573-1-sjhuang@iluvatar.ai
Link: http://lkml.kernel.org/r/20181228083950.20398-1-sjhuang@iluvatar.ai
Signed-off-by: Huang Shijie 
Reviewed-by: Andrew Morton 
Cc: Russell King 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds