kernel/linux.git/include/linux/dma-mapping.h, branch v7.3-rc1

dma-mapping: Add internal shared allocation attribute

2026-07-31T06:40:58+00:00

DMA_ATTR_CC_SHARED describes an existing DMA mapping whose backing memory is already shared, or decrypted, for confidential computing. It is a mapping attribute: callers use it to request a shared DMA address encoding for memory that has already been prepared for shared DMA. Allocation paths need a related but different state. Once the DMA core decides that an allocation must use shared backing pages, the lower-level allocation helpers need to select shared pools, decrypt newly allocated pages, derive the DMA address with the shared-memory translation and restore encryption on free. That state is internal to the DMA-mapping implementation and should not be passed by drivers to dma_alloc_attrs(). Reviewed-by: Jason Gunthorpe Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-10-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski

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: add missing `inline` for `dma_free_attrs`

2026-03-25T07:01:21+00:00

Under an UML build for an upcoming series [1], I got `-Wstatic-in-inline` for `dma_free_attrs`: BINDGEN rust/bindings/bindings_generated.rs - due to target missing In file included from rust/helpers/helpers.c:59: rust/helpers/dma.c:17:2: warning: static function 'dma_free_attrs' is used in an inline function with external linkage [-Wstatic-in-inline] 17 | dma_free_attrs(dev, size, cpu_addr, dma_handle, attrs); | ^ rust/helpers/dma.c:12:1: note: use 'static' to give inline function 'rust_helper_dma_free_attrs' internal linkage 12 | __rust_helper void rust_helper_dma_free_attrs(struct device *dev, size_t size, | ^ | static The issue is that `dma_free_attrs` was not marked `inline` when it was introduced alongside the rest of the stubs. Thus mark it. Fixes: ed6ccf10f24b ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA") Closes: https://lore.kernel.org/rust-for-linux/20260322194616.89847-1-ojeda@kernel.org/ [1] Signed-off-by: Miguel Ojeda Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260325015548.70912-1-ojeda@kernel.org

dma-mapping: fix false kernel-doc comment marker

2026-03-20T11:12:52+00:00

Change /** to /* for the DMA attributes list comment in dma-mapping.h. The comment is not a kernel-doc structured comment and should not use the kernel-doc opening marker. Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Kit Dallege Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260315171001.66010-1-xaum.io@gmail.com

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

dma-mapping: Clarify valid conditions for CPU cache line overlap

2026-03-20T10:33:24+00:00

Rename the DMA_ATTR_CPU_CACHE_CLEAN attribute to better reflect that it is debugging aid to inform DMA core code that CPU cache line overlaps are allowed, and refine the documentation describing its use. Signed-off-by: Leon Romanovsky Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-3-1dde90a7f08b@nvidia.com

dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN

2026-01-01T00:30:02+00:00

When multiple small DMA_FROM_DEVICE or DMA_BIDIRECTIONAL buffers share a cacheline, and DMA_API_DEBUG is enabled, we get this warning: cacheline tracking EEXIST, overlapping mappings aren't supported. This is because when one of the mappings is removed, while another one is active, CPU might write into the buffer. Add an attribute for the driver to promise not to do this, making the overlapping safe, and suppressing the warning. Message-ID: <2d5d091f9d84b68ea96abd545b365dd1d00bbf48.1767601130.git.mst@redhat.com> Reviewed-by: Petr Tesarik Acked-by: Marek Szyprowski Signed-off-by: Michael S. Tsirkin

dma-mapping: add __dma_from_device_group_begin()/end()

2026-01-01T00:27:45+00:00

When a structure contains a buffer that DMA writes to alongside fields that the CPU writes to, cache line sharing between the DMA buffer and CPU-written fields can cause data corruption on non-cache-coherent platforms. Add __dma_from_device_group_begin()/end() annotations to ensure proper alignment to prevent this: struct my_device { spinlock_t lock1; __dma_from_device_group_begin(); char dma_buffer1[16]; char dma_buffer2[16]; __dma_from_device_group_end(); spinlock_t lock2; }; Message-ID: <19163086d5e4704c316f18f6da06bc1c72968904.1767601130.git.mst@redhat.com> Acked-by: Marek Szyprowski Reviewed-by: Petr Tesarik Signed-off-by: Michael S. Tsirkin