linux.git/kernel/dma, branch master

Merge tag 'dma-mapping-7.3-2026-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux

2026-08-27T19:14:19+00:00

Pull dma-mapping fix from Marek Szyprowski: - integer overflow fix for kernel cmdline parser for DMA contiguous initialization code (Alexander Graf) * tag 'dma-mapping-7.3-2026-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: dma-contiguous: fix truncation of numa_cma / cma_pernuma sizes >= 2G

Merge tags 'dma-mapping-7.3-2026-08-24' and 'dma-mapping-7.3-2026-08-24-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux

2026-08-24T18:35:46+00:00

Pull dma-mapping updates from Marek Szyprowski: - swiotlb: - new configuration option for the default pool size (Jagadeesh Pagadala) - reduce overhead for high watermark tracking (chenhuguanshen) - minor code cleanups and improvements (Vova Sharaienko, Honglei Huang and Marek Szyprowski) - add proper tracking of the shared DMA state through direct, pool and swiotlb paths (Aneesh Kumar K.V) This is important for confidential-computing * tag 'dma-mapping-7.3-2026-08-24' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: dma/swiotlb: decouple high watermark tracking from CONFIG_DEBUG_FS MAINTAINERS: update tree for DMA MAPPING HELPERS dma/swiotlb: introduce Kconfig option for compile-time default pool size dma-direct: Improve readability of the dma_direct_map_sg() for P2PDMA case iommu/dma: simplify dma_iova_destroy() and drop the free_iova helper dma-coherent: use KiB in DMA allocation logs dma-coherent: fix spacing coding style issue * tag 'dma-mapping-7.3-2026-08-24-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: (23 commits) swiotlb: remove unused SWIOTLB_FORCE flag dma: swiotlb: handle set_memory_decrypted() failures dma: swiotlb: free dynamic pools from process context dma-direct: rename ret to cpu_addr in alloc helpers dma-direct: select DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED dma-direct: set decrypted flag for remapped DMA allocations dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED dma-direct: Move dma_direct_map_phys() to dma/direct.c dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED dma: swiotlb: pass mapping attributes by reference dma-pool: track decrypted atomic pools and select them via attrs dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths dma-mapping: Add internal shared allocation attribute coco: arm64: s390: powerpc: Mark secure guests with CC_ATTR_GUEST_MEM_ENCRYPT dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages s390: Expose protected virtualization through cc_platform_has() swiotlb: Preserve allocation virtual address for dynamic pools dma: free atomic pool pages by physical address ...

dma-contiguous: fix truncation of numa_cma / cma_pernuma sizes >= 2G

2026-08-24T13:40:07+00:00

numa_cma=0:4G reserves nothing at all. dma_numa_cma_reserve() copies the requested size into a local int before handing it to cma_declare_contiguous_nid(), so 0x100000000 truncates to zero and the loop skips the node silently. Both parameters are documented in kernel-parameters.txt as nn[MG], so that is the syntax the documentation invites. Which bits survive decides what a request turns into: 4G, 8G and 16G reserve nothing, 2G, 3G and 6G sign-extend into a size the allocator rejects with a warning, and 5G quietly reserves 1G. It reaches further than those parameters. On a CMA_SIZE_PERNUMA kernel with no per-node parameter, dma_numa_cma_reserve() takes the per-node size from the default area, so a plain cma=4G on a multi-node machine feeds that size through the same local and loses every per-node area. numa_cma_size[] and pernuma_size_bytes are both phys_addr_t, so use it for the local too, and give early_numa_cma() separate variables for the node id and the size while in there. Fixes: d5cae2261b86 ("dma-contiguous: simplify numa cma area handling") Cc: stable@vger.kernel.org Assisted-by: Kiro:claude-opus-5 Signed-off-by: Alexander Graf Reviewed-by: Feng Tang Link: https://lore.kernel.org/r/20260821224252.70640-1-graf@amazon.com Signed-off-by: Marek Szyprowski

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2026-08-21T18:23:20+00:00

Pull SCSI updates from James Bottomley: "One new driver: leapraid (similar to mpi3mr but OK'd by Broadcom). The usual suspects for driver updates (ufs, qla2xxx, smartpqi, zfcp, fnic, ibmvfc) plus a few small core updates: a fix for an uninitialized sg list pad bytes plus the removal of the dma mask check for max sectors. The big update in the sd driver is mostly code refactoring for obscure error leg handling" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (195 commits) scsi: fnic: Fix built-in NVMe/FC build scsi: fnic: Fix invalid comparison for error scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() scsi: zfcp: Enable CONTEXT_ANALYSIS scsi: zfcp: Add __must_hold() attribute to zfcp_qdio_sbal_get() scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock scsi: storvsc: Support manual scans for all Hyper-V targets scsi: sd: Fix sd_done() sense handling condition scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails scsi: sd: Fix error handling in sd_probe() after large pool creation failure scsi: leapraid: Add driver documentation scsi: leapraid: Add new SCSI driver scsi: ufs: Add support for the aggregated read query opcode scsi: ufs: Use unsigned types for the BSG query scsi: ibmvfc: Fix spelling mistake "Deleteing" -> "Deleting" scsi: qla2xxx: Update version to 12.00.00.2607b2 scsi: qla2xxx: Bound i2c->length in I2C bsg handlers scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[] scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak ...

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