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

Merge tag 'dma-mapping-7.4-2026-10-21' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux

2026-10-24T00:31:51+00:00

Pull dma-mapping updates from Marek Szyprowski:

 - several SWIOTLB initialization cleanups (Aneesh Kumar K.V, Francesco
   Valla)

 - exact page allocation for DMA pages (Qingfang Deng)

 - tools/dma build fixes (Sasha Levin)

 - minor fixes for various corner cases (Marek Szyprowski, Leon
   Romanovsky) and code cleanup (John Garry)

* tag 'dma-mapping-7.4-2026-10-21' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  dma-debug: Skip cacheline tracking for MMIO mappings
  tools/dma: fix building from the top level with O=
  tools/dma: fix building with O=
  dma: swiotlb: Track whether the pool size was explicitly set
  dma: swiotlb: Consolidate slab rounding
  dma: swiotlb: Rename swiotlb_size_or_default()
  dma: swiotlb: use KiB in restricted pool allocation log
  dma-direct: Restore arch_dma_alloc() for the DMA_ATTR_NO_KERNEL_MAPPING case
  MAINTAINERS: Add files to the DMA MAPPING HELPERS entry
  dma-mapping: use exact allocation for DMA pages
  dma-mapping: rename dma_opt_mapping_size()

dma-debug: Skip cacheline tracking for MMIO mappings

2026-10-14T13:07:22+00:00

Mapping one MMIO dma-buf for many RDMA importers overflows dma-debug's
cacheline overlap counter and triggers a warning. DMA_ATTR_MMIO mappings
must never be CPU-cacheable, so CPU cacheline overlap tracking does not
apply to them.

Skip MMIO entries in both cacheline insertion and removal. Keep them in
the DMA entry hash so mapping and unmapping checks still run.

The reported warning was:
 ------------[ cut here ]------------
DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000e040000400
WARNING: kernel/dma/debug.c:465 at add_dma_entry+0x3b5/0x470, CPU#58: dtr/5264
Modules linked in: xt_conntrack xt_MASQUERADE ip6table_nat ip6table_filter ip6_tables iptable_nat nf_nat xt_addrtype rpcsec_gss_krb5 krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm nvidia(O) mlx5_fwctl nvidia_drm(O) mlx5_ib ib_uverbs_support ib_core zram zsmalloc fuse mlx5_core
CPU: 58 UID: 0 PID: 5264 Comm: dtr Tainted: G           O      J 7.3.0-rc6_for_upstream_debug_2026_10_08_13_46 #1.fc40 PREEMPTLAZY
Tainted: [O]=OOT_MODULE, [J]=FWCTL
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:add_dma_entry+0x3bf/0x470
Code: ac e8 f5 89 6e 00 e9 47 fe ff ff 41 f7 c6 00 18 00 00 75 9f 83 fb 07 7e 9a 48 8d 3d eb 02 5f 04 be 07 00 00 00 48 8d 54 24 30 <67> 48 0f b9 3a eb 82 0f 0b 48 c7 c7 80 d3 2a 85 4c 89 e6 e8 a9 1f
RSP: 0018:ff110001bcb7f230 EFLAGS: 00010002
RAX: 0000000000000006 RBX: 0000000000000008 RCX: 0000000000000000
RDX: ff110001bcb7f260 RSI: 0000000000000007 RDI: ffffffff85cfd070
RBP: 000000e040000400 R08: 0000000000000000 R09: ffe21c0044b8abf5
R10: ff11000225c55faf R11: 0000000000000000 R12: 0000000000000246
R13: 1fe220003796fe48 R14: 0000000000000400 R15: 00000000ffffffff
FS:  00007fa8f91e6b80(0000) GS:ff11000eb81cc000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa8f5ca80f0 CR3: 0000000164871004 CR4: 0000000000373eb0
Call Trace:
 
 ? check_sync+0x2070/0x2070
 ? find_held_lock+0x2b/0x80
 ? debug_dma_map_phys+0x588/0x840
 debug_dma_map_phys+0x267/0x840
 ? dma_debug_add_bus+0xd0/0xd0
 ? __sg_alloc_table+0x2b7/0x4d0
 dma_map_phys+0x10a/0x330
 ? sg_miter_start+0x130/0x130
 dma_buf_phys_vec_to_sgt+0x565/0xed0
 uverbs_dmabuf_map+0x158/0x340 [ib_uverbs]
 ? uverbs_dmabuf_unpin+0x10/0x10 [ib_uverbs]
 dma_buf_map_attachment+0x138/0x690
 ib_umem_dmabuf_map_pages+0x249/0xc90 [ib_core]
 pagefault_dmabuf_mr+0x172/0xf80 [mlx5_ib]
 ? do_raw_spin_unlock+0x54/0x210
 mlx5_ib_init_dmabuf_mr+0x13e/0x200 [mlx5_ib]
[... '?' frames and user-space registers omitted ...]
 reg_user_mr_dmabuf+0x3bf/0x760 [mlx5_ib]
 mlx5_ib_reg_user_mr_dmabuf+0x2dd/0x13b0 [mlx5_ib]
 ib_uverbs_handler_UVERBS_METHOD_REG_MR+0x76d/0xd90 [ib_uverbs]
 ib_uverbs_cmd_verbs+0x2337/0x31c0 [ib_uverbs]
 ib_uverbs_ioctl+0x1c7/0x350 [ib_uverbs]
 __x64_sys_ioctl+0x72c/0x11f0
 do_syscall_64+0xa1/0x4f0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
 
 ---[ end trace 0000000000000000 ]---

Signed-off-by: Leon Romanovsky 
Reviewed-by: Robin Murphy 
Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine")
Link: https://lore.kernel.org/r/20261013-dma-debug-fixes-v1-1-1ad1f471cc61@nvidia.com
Signed-off-by: Marek Szyprowski

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

2026-10-09T22:49:55+00:00

Pull dma-mapping fixes from Marek Szyprowski:
 "Two more fixes for the corner cases in the DMA-mapping SWIOTLB code
  (Peng Fan and Marek Szyprowski)"

* tag 'dma-mapping-7.3-2026-10-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  swiotlb: fix default_swiotlb_limit() for non-growable default pool
  iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys

dma: swiotlb: Track whether the pool size was explicitly set

2026-10-09T15:12:07+00:00

swiotlb_adjust_size() must not override a pool size supplied through the
swiotlb= command-line parameter.

Currently, it determines whether a size was supplied by comparing
default_nslabs with IO_TLB_DEFAULT_SIZE. This fails when the user
explicitly requests the compiled-in default size, allowing the request
to be overwritten by automatic pool sizing.

Record whether swiotlb= supplied a numeric size in swiotlb_cmdline_size_set
and check that flag directly before adjusting the pool size.

Reviewed-by: Catalin Marinas 
Reviewed-by: Robin Murphy 
Signed-off-by: Aneesh Kumar K.V (Arm) 
Link: https://lore.kernel.org/r/20260924060756.1325156-4-aneesh.kumar@kernel.org
Signed-off-by: Marek Szyprowski

dma: swiotlb: Consolidate slab rounding

2026-10-09T15:12:06+00:00

Pass the area count explicitly to swiotlb_calc_nslabs() and keep the
calculation separate from updates to the default_nslabs . Move the
default_nslabs update into swiotlb_adjust_nareas().

Round slabs to a power of two even before the area count is initialized.
For early swiotlb_adjust_size() calls, this moves rounding from area
initialization to size adjustment, so early queries see the rounded
size.

Signed-off-by: Aneesh Kumar K.V (Arm) 
Link: https://lore.kernel.org/r/20260924060756.1325156-3-aneesh.kumar@kernel.org
Signed-off-by: Marek Szyprowski

dma: swiotlb: Rename swiotlb_size_or_default()

2026-10-09T15:12:06+00:00

Rename swiotlb_size_or_default() to swiotlb_default_pool_size() to make
clear that it returns the current size of the default SWIOTLB pool.
This includes changes made by command-line options or sizing heuristics,
not just the compiled-in default.

No functional change.

Signed-off-by: Aneesh Kumar K.V (Arm) 
Link: https://lore.kernel.org/r/20260924060756.1325156-2-aneesh.kumar@kernel.org
Signed-off-by: Marek Szyprowski

dma: swiotlb: use KiB in restricted pool allocation log

2026-10-09T15:12:06+00:00

Update the allocation logs for restricted memory pools to use KiBs
instead of MiBs, to avoid truncation when the size of the memory area is
not a multiple of a MiB.

Without this modification, pools smaller than 1MiB are logged as 0MiB.

The same modification has already been performed for coherent memory
pools [1].

Link: https://lore.kernel.org/all/20260629223759.2637162-1-sharaienko@google.com/ [1]
Signed-off-by: Francesco Valla 
Link: https://lore.kernel.org/r/20261008-swiotlb-size-print-v1-1-374493b5c5a6@valla.it
Signed-off-by: Marek Szyprowski

dma-direct: Restore arch_dma_alloc() for the DMA_ATTR_NO_KERNEL_MAPPING case

2026-10-09T15:12:06+00:00

Commit 849facea92fa ("dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING
handling") moved the DMA_ATTR_NO_KERNEL_MAPPING shortcut in
dma_direct_alloc() in front of the arch_dma_alloc() call. Architectures
providing their own DMA coherent allocator (CONFIG_ARCH_HAS_DMA_ALLOC)
therefore no longer see such requests. ARM 32bit is one of such. Lack of
the call to arch_dma_alloc() results in the lack of proper cache
management on HighMem pages.

Take the dma-direct shortcut only for coherent devices or when the
architecture doesn't provide arch_dma_alloc(). While touching this,
move that check into separate function to avoid duplication in alloc
and free paths.

Fixes: 849facea92fa ("dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling")
Reported-by: Aneesh Kumar K.V 
Closes: https://lore.kernel.org/all/yq5ams2akznl.fsf@kernel.org/
Assisted-by: Claude Opus 5.5 
Link: https://lore.kernel.org/r/20260930135734.1013905-1-m.szyprowski@samsung.com
Signed-off-by: Marek Szyprowski

swiotlb: fix default_swiotlb_limit() for non-growable default pool

2026-10-08T10:13:28+00:00

Commit ad96ce3252db ("swiotlb: determine potential physical address
limit") changed default_swiotlb_limit() to return the maximum physical
address that could ever be used by dynamically allocated pools, so that
the value stays constant when CONFIG_SWIOTLB_DYNAMIC=y. However,
io_tlb_default_mem.phys_limit is returned even when the default pool
cannot grow, e.g. when swiotlb_init_remap() is called with a remap
callback.

This breaks Xen dom0 on x86: pci_xen_swiotlb_init() passes SWIOTLB_ANY
and xen_swiotlb_fixup(), so phys_limit is set to the top of dom0 memory,
although xen_swiotlb_fixup() makes the default pool below the 32-bit
boundary. xen_swiotlb_dma_supported() then rejects 32-bit DMA masks,
even though the bounce buffer is perfectly usable by such devices.

Return phys_limit only if the default pool can actually grow, otherwise
report the real end of the default pool, like in the
!CONFIG_SWIOTLB_DYNAMIC case.

Reported-by: Andreas Greve 
Reported-by: James Dingwall 
Fixes: ad96ce3252db ("swiotlb: determine potential physical address limit")
Closes: https://lore.kernel.org/xen-devel/f74668db-52fd-4575-8372-7bfdf10d62ac@a-greve.de/
Cc: stable@vger.kernel.org
Assisted-by: Claude Opus 5.5 (1M context) 
Tested-by: James Dingwall 
Link: https://lore.kernel.org/all/20261005070518.1590097-1-m.szyprowski@samsung.com/
Signed-off-by: Marek Szyprowski

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

2026-09-17T15:03:37+00:00

Pull dma-mapping fixes from Marek Szyprowski:
 "A few fixes for the DMA-mapping code:

   - resolved regression in accessing encrypted memory by IOMMU-backed
     devices (Aneesh Kumar K.V)

   - improved failure handling and removed rare bug in swiotlb/highmem
     (Donggeun Yoo)"

* tag 'dma-mapping-7.3-2026-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
  dma-mapping: don't trace the DMA address when the allocation fails
  swiotlb: use the adjusted address for the highmem page lookup
  dma-coherent: report a failed reserved memory assignment