linux.git/kernel/dma/mapping.c, branch v7.2-rc1

Merge tag 'dma-mapping-7.2-2026-06-16' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux

2026-06-17T19:20:21+00:00

Pull dma-mapping updates from Marek Szyprowski:

 - added checks for DMA attributes in the debug code, especially to
   ensure that mappings are created and released with matching
   attributes (Leon Romanovsky)

 - better default configuration for CMA on NUMA machines (Feng Tang)

 - code cleanup in dma benchmark tool (Rosen Penev)

* tag 'dma-mapping-7.2-2026-06-16' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  dma: map_benchmark: turn dma_sg_map_param buf into a flexible array
  dma-contiguous: simplify numa cma area handling
  dma-contiguous: add kconfig option to setup numa cma area if not configured explicitly
  dma-debug: Ensure mappings are created and released with matching attributes
  dma-debug: Feed DMA attribute for unmapping flows too
  dma-debug: Record DMA attributes in debug entry
  dma-debug: Remove unused DMA attribute parameter
  ntb: Use consistent DMA attributes when freeing DMA mappings
  ntb: Store original DMA address for future release

Merge tag 'v7.1-rc5' into driver-core-next

2026-05-25T00:40:57+00:00

We need the driver-core fixes in here as well to build on top of.

Signed-off-by: Danilo Krummrich

dma-mapping: move dma_map_resource() sanity check into debug code

2026-05-18T07:04:59+00:00

dma_map_resource() uses pfn_valid() to ensure the range is not RAM.
However, pfn_valid() only checks for availability of the memory map for
a PFN but it does not ensure that the PFN is actually backed by RAM. On
ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that
share a section with RAM will falsely trigger the WARN_ON_ONCE and cause
dma_map_resource() to return DMA_MAPPING_ERROR.

This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because
the SPI FIFO register (0xfe204004) falls in the same sparsemem section
as the end of RAM (0xf8000000-0xfbffffff), both in section 31
(0xf8000000-0xffffffff).

Move the sanity check from dma_map_resource() into debug_dma_map_phys()
and replace the unreliable pfn_valid() with pfn_valid() &&
!PageReserved(), which correctly identifies actual usable RAM without
false positives for MMIO regions that happen to have struct pages.

Since dma_map_resource() is dma_map_phys(DMA_ATTR_MMIO), the check
applies equally to both APIs. Any non-reserved page represents kernel
memory to a sufficient degree that using DMA_ATTR_MMIO on it is almost
certainly wrong and risks breaking coherency on non-coherent platforms.
ZONE_DEVICE pages used for PCI P2P DMA (MEMORY_DEVICE_PCI_P2PDMA) have
PageReserved set, so they will not trigger a false positive.

The check no longer blocks the mapping and uses err_printk() to
integrate with dma-debug filtering.

Fixes: f7326196a781 ("dma-mapping: export new dma_*map_phys() interface")
Reviewed-by: Robin Murphy 
Signed-off-by: Jianpeng Chang 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260513072209.1486986-1-jianpeng.chang.cn@windriver.com

dma-debug: Feed DMA attribute for unmapping flows too

2026-05-08T20:28:19+00:00

There are multiple unmapping flows which didn't provide DMA attributes,
which limited DMA debug code to compare the mapping and unmapping
attributes. Let's fix it.

Signed-off-by: Leon Romanovsky 
Reviewed-by: Samiullah Khawaja 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260501-dma-attrs-debug-v2-5-8dbac75cd501@nvidia.com

dma-debug: Remove unused DMA attribute parameter

2026-05-08T20:28:19+00:00

debug_dma_alloc_pages() always receives a DMA attribute value of 0,
because dma_alloc_pages() never receives any attributes from its callers.
As preparation for upcoming patches, remove this unused attribute from
the debug routine.

Signed-off-by: Leon Romanovsky 
Reviewed-by: Samiullah Khawaja 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260501-dma-attrs-debug-v2-3-8dbac75cd501@nvidia.com

driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()

2026-04-26T21:43:05+00:00

In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "dma_ops_bypass" over to the "flags"
field so modifications are safe.

Cc: Christoph Hellwig 
Cc: Alexey Kardashevskiy 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Signed-off-by: Douglas Anderson 
Link: https://patch.msgid.link/20260406162231.v5.5.If62b84471ef2c85e7ad250f0468867d6dba965ab@changeid
Signed-off-by: Danilo Krummrich

driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()

2026-04-26T21:38:57+00:00

In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "dma_skip_sync" over to the "flags"
field so modifications are safe.

Cc: Alexander Lobakin 
Cc: Eric Dumazet 
Cc: Christoph Hellwig 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Signed-off-by: Douglas Anderson 
Link: https://patch.msgid.link/20260406162231.v5.4.Icf072aa4184dd86a88fa8ca195b09d1651984000@changeid
Signed-off-by: Danilo Krummrich

dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory

2026-04-02T05:29:33+00:00

Current CC designs don't place a vIOMMU in front of untrusted devices.
Instead, the DMA API forces all untrusted device DMA through swiotlb
bounce buffers (is_swiotlb_force_bounce()) which copies data into
shared memory on behalf of the device.

When a caller has already arranged for the memory to be shared
via set_memory_decrypted(), the DMA API needs to know so it can map
directly using the unencrypted physical address rather than bounce
buffering. Following the pattern of DMA_ATTR_MMIO, add
DMA_ATTR_CC_SHARED for this purpose. Like the MMIO case, only the
caller knows what kind of memory it has and must inform the DMA API
for it to work correctly.

Signed-off-by: Jiri Pirko 
Reviewed-by: Jason Gunthorpe 
Acked-by: Sumit Semwal 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260325192352.437608-2-jiri@resnulli.us

Merge tag 'dma-mapping-7.0-2026-03-25' into dma-mapping-for-next

2026-03-25T17:25:43+00:00

dma-mapping fixes for Linux 7.0

A set of fixes for DMA-mapping subsystem, which resolve false-positive
warnings from KMSAN and DMA-API debug (Shigeru Yoshida and Leon
Romanovsky) as well as a simple build fix (Miguel Ojeda).

Signed-off-by: Marek Szyprowski

dma-mapping: Introduce DMA require coherency attribute

2026-03-20T11:05:36+00:00

The mapping buffers which carry this attribute require DMA coherent system.
This means that they can't take SWIOTLB path, can perform CPU cache overlap
and doesn't perform cache flushing.

Signed-off-by: Leon Romanovsky 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-4-1dde90a7f08b@nvidia.com