linux-next.git/kernel/dma, branch master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git

2026-08-19T11:47:41+00:00

Merge branch 'dma-mapping-for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git

2026-08-19T11:27:42+00:00

Merge branch 'dma-mapping-coco' into dma-mapping-for-next

2026-08-13T06:11:08+00:00

Signed-off-by: Marek Szyprowski

dma/swiotlb: decouple high watermark tracking from CONFIG_DEBUG_FS

2026-08-13T06:02:35+00:00

Under heavy concurrent DMA traffic on CoCo VMs, inc_used_and_hiwater() performs an atomic_long_add_return() plus a CAS loop on the global used_hiwater, and dec_used() performs an atomic_long_sub() on total_used. All CPUs contend on the same cacheline, causing measurable throughput degradation at scale. Historically these counters were only compiled in under CONFIG_DEBUG_FS, which means production kernels with debugfs paid the atomic overhead unconditionally. Make the tracking boot-time opt-in instead so that it is disabled by default with near-zero overhead via static_call, and can be enabled via "swiotlb=track_hiwater" parameter on demand for debugging. Note that when CONFIG_DEBUG_FS is enabled but hiwater tracking is disabled, the "io_tlb_used" metric reports an approximate value rather than an instantaneously exact one. Suggested-by: Fan Du Signed-off-by: Jun Miao Co-developed-by: Fan Du Signed-off-by: Fan Du Tested-by: chenhuguanshen Signed-off-by: chenhuguanshen Reviewed-by: Michael Kelley Tested-by: Michael Kelley Link: https://lore.kernel.org/r/20260812070459.637077-1-frankchen158@126.com Signed-off-by: Marek Szyprowski

mm: prefer vma_[start,end]_pgoff() to vma->vm_pgoff in kernel/

2026-08-05T02:19:01+00:00

Be consistent in using vma_start_pgoff() and vma_end_pgoff(), which clearly indicates which part of the VMA the page offset refers to and aids greppability. This is part of a broader series laying the ground to provide a virtual page offset for MAP_PRIVATE-file backed anon folios. No functional change intended. Link: https://lore.kernel.org/20260710-b4-pre-scalable-cow-v2-19-2a5aa403d977@kernel.org Signed-off-by: Lorenzo Stoakes Acked-by: Marek Szyprowski # for kernel/dma Reviewed-by: Gregory Price Acked-by: Pedro Falcato Reviewed-by: Vlastimil Babka (SUSE) Cc: Ackerley Tng Cc: David Hildenbrand (Arm) Cc: Kai Huang Cc: SJ Park Cc: Thomas Zimmermann Cc: Liam R. Howlett (Oracle) Cc: Zi Yan Signed-off-by: Andrew Morton

swiotlb: remove unused SWIOTLB_FORCE flag

2026-07-31T06:44:52+00:00

SWIOTLB_FORCE has no remaining in-tree users. Forced bouncing is now controlled through the swiotlb=force command line option via swiotlb_force_bounce. Remove the unused flag and simplify the force_bounce initialization. Reviewed-by: Jason Gunthorpe Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260717180442.110954-24-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski

dma: swiotlb: handle set_memory_decrypted() failures

2026-07-31T06:44:52+00:00

Check the return value when converting swiotlb pools between encrypted and decrypted mappings. If the default pool cannot be decrypted after early initialization, mark the pool fully used so it cannot satisfy future bounce allocations. For late initialization, return the `set_memory_decrypted()` failure. For restricted DMA pools, fail device initialization if the reserved pool cannot be decrypted. This prevents swiotlb from using pools whose encryption attributes do not match their metadata, and avoids returning pages with uncertain encryption state back to the allocator. Reviewed-by: Jason Gunthorpe Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260717180442.110954-23-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski

dma: swiotlb: free dynamic pools from process context

2026-07-31T06:44:52+00:00

swiotlb_dyn_free() is used after removing a dynamic swiotlb pool from RCU-protected lists. It can call swiotlb_free_tlb(), which may need to restore the encryption state of an unencrypted pool with set_memory_encrypted() before freeing the pages. RCU callbacks run in atomic context, but set_memory_encrypted() is not guaranteed to be atomic-safe on all architectures. For example, page attribute updates may allocate page tables or take sleeping locks. Use queue_rcu_work() for dynamic pool freeing instead. This keeps the RCU grace period before freeing a published pool, while running the actual pool teardown from workqueue context. Use the same helper for the transient-pool error path, since that path may also be reached from atomic DMA mapping context. Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260717180442.110954-22-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski

dma-direct: rename ret to cpu_addr in alloc helpers

2026-07-31T06:44:52+00:00

ret in dma_direct_alloc() and dma_direct_alloc_pages() holds the returned CPU mapping, not a generic return value. Rename it to cpu_addr and update the remaining uses to match. This makes the allocation paths easier to follow and keeps the local naming consistent with what the variable actually represents. Reviewed-by: Jason Gunthorpe Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Petr Tesarik Signed-off-by: Aneesh Kumar K.V (Arm) Link: https://lore.kernel.org/r/20260717180442.110954-21-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski

dma-direct: select DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED

2026-07-31T06:44:52+00:00

Make the dma-direct helpers derive the DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED instead of implicitly relying on force_dma_unencrypted() inside phys_to_dma_direct() Pass an explicit unencrypted/decrypted state into phys_to_dma_direct(), make the alloc paths return DMA addresses that match the requested buffer encryption state. Also only call dma_set_decrypted() when __DMA_ATTR_ALLOC_CC_SHARED is actually set. Reviewed-by: Jason Gunthorpe Tested-by: Jiri Pirko Tested-by: Michael Kelley Tested-by: Mostafa Saleh Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-20-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski