Documentation/core-api/dma-api.rst | 4 +- Documentation/core-api/dma-attributes.rst | 18 ++++ arch/powerpc/kernel/dma-iommu.c | 4 +- block/blk-mq-dma.c | 15 ++- drivers/iommu/dma-iommu.c | 61 ++++++------ drivers/nvme/host/pci.c | 18 +++- drivers/virtio/virtio_ring.c | 4 +- drivers/xen/swiotlb-xen.c | 21 +++- include/linux/blk-mq-dma.h | 6 +- include/linux/blk_types.h | 2 + include/linux/dma-direct.h | 2 - include/linux/dma-map-ops.h | 8 +- include/linux/dma-mapping.h | 33 +++++++ include/linux/iommu-dma.h | 11 +-- include/linux/kmsan.h | 9 +- include/linux/page-flags.h | 1 + include/trace/events/dma.h | 9 +- kernel/dma/debug.c | 82 ++++------------ kernel/dma/debug.h | 37 ++----- kernel/dma/direct.c | 22 +---- kernel/dma/direct.h | 57 +++++++---- kernel/dma/mapping.c | 112 +++++++++++++--------- kernel/dma/ops_helpers.c | 6 +- mm/hmm.c | 19 ++-- mm/kmsan/hooks.c | 10 +- rust/kernel/dma.rs | 3 + tools/virtio/linux/kmsan.h | 2 +- 27 files changed, 312 insertions(+), 264 deletions(-)
From: Leon Romanovsky <leonro@nvidia.com> Changelog: v6: * Based on "dma-debug: don't enforce dma mapping check on noncoherent allocations" patch. * Removed some unused variables from kmsan conversion. * Fixed missed ! in dma check. v5: https://lore.kernel.org/all/cover.1756822782.git.leon@kernel.org * Added Jason's and Keith's Reviewed-by tags * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys * Jason's cleanup suggestions v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/ * Fixed kbuild error with mismatch in kmsan function declaration due to rebase error. v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org * Fixed typo in "cacheable" word * Simplified kmsan patch a lot to be simple argument refactoring v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org * Used commit messages and cover letter from Jason * Moved setting IOMMU_MMIO flag to dma_info_to_prot function * Micro-optimized the code * Rebased code on v6.17-rc1 v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org * Added new DMA_ATTR_MMIO attribute to indicate PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path. * Rewrote dma_map_* functions to use thus new attribute v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/ ------------------------------------------------------------------------ This series refactors the DMA mapping to use physical addresses as the primary interface instead of page+offset parameters. This change aligns the DMA API with the underlying hardware reality where DMA operations work with physical addresses, not page structures. The series maintains export symbol backward compatibility by keeping the old page-based API as wrapper functions around the new physical address-based implementations. This series refactors the DMA mapping API to provide a phys_addr_t based, and struct-page free, external API that can handle all the mapping cases we want in modern systems: - struct page based cacheable DRAM - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable MMIO - struct page-less PCI peer to peer non-cacheable MMIO - struct page-less "resource" MMIO Overall this gets much closer to Matthew's long term wish for struct-pageless IO to cacheable DRAM. The remaining primary work would be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on phys_addr_t without a struct page. The general design is to remove struct page usage entirely from the DMA API inner layers. For flows that need to have a KVA for the physical address they can use kmap_local_pfn() or phys_to_virt(). This isolates the struct page requirements to MM code only. Long term all removals of struct page usage are supporting Matthew's memdesc project which seeks to substantially transform how struct page works. Instead make the DMA API internals work on phys_addr_t. Internally there are still dedicated 'page' and 'resource' flows, except they are now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both flows use the same phys_addr_t. When DMA_ATTR_MMIO is specified things work similar to the existing 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), pfn_valid(), etc are never called on the phys_addr_t. This requires rejecting any configuration that would need swiotlb. CPU cache flushing is not required, and avoided, as ATTR_MMIO also indicates the address have no cacheable mappings. This effectively removes any DMA API side requirement to have struct page when DMA_ATTR_MMIO is used. In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, except on the common path of no cache flush, no swiotlb it never touches a struct page. When cache flushing or swiotlb copying kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU usage. This was already the case on the unmap side, now the map side is symmetric. Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA path must also set it. This corrects some existing bugs where iommu mappings for P2P MMIO were improperly marked IOMMU_CACHE. Since ATTR_MMIO is made to work with all the existing DMA map entry points, particularly dma_iova_link(), this finally allows a way to use the new DMA API to map PCI P2P MMIO without creating struct page. The VFIO DMABUF series demonstrates how this works. This is intended to replace the incorrect driver use of dma_map_resource() on PCI BAR addresses. This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation. Thanks Leon Romanovsky (16): dma-mapping: introduce new DMA attribute to indicate MMIO memory iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link(). dma-debug: refactor to use physical addresses for page mapping dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys iommu/dma: implement DMA_ATTR_MMIO for iommu_dma_(un)map_phys() dma-mapping: convert dma_direct_*map_page to be phys_addr_t based kmsan: convert kmsan_handle_dma to use physical addresses dma-mapping: implement DMA_ATTR_MMIO for dma_(un)map_page_attrs() xen: swiotlb: Open code map_resource callback dma-mapping: export new dma_*map_phys() interface mm/hmm: migrate to physical address-based DMA mapping API mm/hmm: properly take MMIO path block-dma: migrate to dma_map_phys instead of map_page block-dma: properly take MMIO path nvme-pci: unmap MMIO pages with appropriate interface Documentation/core-api/dma-api.rst | 4 +- Documentation/core-api/dma-attributes.rst | 18 ++++ arch/powerpc/kernel/dma-iommu.c | 4 +- block/blk-mq-dma.c | 15 ++- drivers/iommu/dma-iommu.c | 61 ++++++------ drivers/nvme/host/pci.c | 18 +++- drivers/virtio/virtio_ring.c | 4 +- drivers/xen/swiotlb-xen.c | 21 +++- include/linux/blk-mq-dma.h | 6 +- include/linux/blk_types.h | 2 + include/linux/dma-direct.h | 2 - include/linux/dma-map-ops.h | 8 +- include/linux/dma-mapping.h | 33 +++++++ include/linux/iommu-dma.h | 11 +-- include/linux/kmsan.h | 9 +- include/linux/page-flags.h | 1 + include/trace/events/dma.h | 9 +- kernel/dma/debug.c | 82 ++++------------ kernel/dma/debug.h | 37 ++----- kernel/dma/direct.c | 22 +---- kernel/dma/direct.h | 57 +++++++---- kernel/dma/mapping.c | 112 +++++++++++++--------- kernel/dma/ops_helpers.c | 6 +- mm/hmm.c | 19 ++-- mm/kmsan/hooks.c | 10 +- rust/kernel/dma.rs | 3 + tools/virtio/linux/kmsan.h | 2 +- 27 files changed, 312 insertions(+), 264 deletions(-) -- 2.51.0
On 09.09.2025 15:27, Leon Romanovsky wrote: > From: Leon Romanovsky <leonro@nvidia.com> > > Changelog: > v6: > * Based on "dma-debug: don't enforce dma mapping check on noncoherent > allocations" patch. > * Removed some unused variables from kmsan conversion. > * Fixed missed ! in dma check. > v5: https://lore.kernel.org/all/cover.1756822782.git.leon@kernel.org > * Added Jason's and Keith's Reviewed-by tags > * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys > * Jason's cleanup suggestions > v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/ > * Fixed kbuild error with mismatch in kmsan function declaration due to > rebase error. > v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org > * Fixed typo in "cacheable" word > * Simplified kmsan patch a lot to be simple argument refactoring > v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org > * Used commit messages and cover letter from Jason > * Moved setting IOMMU_MMIO flag to dma_info_to_prot function > * Micro-optimized the code > * Rebased code on v6.17-rc1 > v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org > * Added new DMA_ATTR_MMIO attribute to indicate > PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path. > * Rewrote dma_map_* functions to use thus new attribute > v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/ > ------------------------------------------------------------------------ > > This series refactors the DMA mapping to use physical addresses > as the primary interface instead of page+offset parameters. This > change aligns the DMA API with the underlying hardware reality where > DMA operations work with physical addresses, not page structures. > > The series maintains export symbol backward compatibility by keeping > the old page-based API as wrapper functions around the new physical > address-based implementations. > > This series refactors the DMA mapping API to provide a phys_addr_t > based, and struct-page free, external API that can handle all the > mapping cases we want in modern systems: > > - struct page based cacheable DRAM > - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable > MMIO > - struct page-less PCI peer to peer non-cacheable MMIO > - struct page-less "resource" MMIO > > Overall this gets much closer to Matthew's long term wish for > struct-pageless IO to cacheable DRAM. The remaining primary work would > be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on > phys_addr_t without a struct page. > > The general design is to remove struct page usage entirely from the > DMA API inner layers. For flows that need to have a KVA for the > physical address they can use kmap_local_pfn() or phys_to_virt(). This > isolates the struct page requirements to MM code only. Long term all > removals of struct page usage are supporting Matthew's memdesc > project which seeks to substantially transform how struct page works. > > Instead make the DMA API internals work on phys_addr_t. Internally > there are still dedicated 'page' and 'resource' flows, except they are > now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both > flows use the same phys_addr_t. > > When DMA_ATTR_MMIO is specified things work similar to the existing > 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), > pfn_valid(), etc are never called on the phys_addr_t. This requires > rejecting any configuration that would need swiotlb. CPU cache > flushing is not required, and avoided, as ATTR_MMIO also indicates the > address have no cacheable mappings. This effectively removes any > DMA API side requirement to have struct page when DMA_ATTR_MMIO is > used. > > In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, > except on the common path of no cache flush, no swiotlb it never > touches a struct page. When cache flushing or swiotlb copying > kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU > usage. This was already the case on the unmap side, now the map side > is symmetric. > > Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users > must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA > path must also set it. This corrects some existing bugs where iommu > mappings for P2P MMIO were improperly marked IOMMU_CACHE. > > Since ATTR_MMIO is made to work with all the existing DMA map entry > points, particularly dma_iova_link(), this finally allows a way to use > the new DMA API to map PCI P2P MMIO without creating struct page. The > VFIO DMABUF series demonstrates how this works. This is intended to > replace the incorrect driver use of dma_map_resource() on PCI BAR > addresses. > > This series does the core code and modern flows. A followup series > will give the same treatment to the legacy dma_ops implementation. Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it works fine in linux-next. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote: > On 09.09.2025 15:27, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro@nvidia.com> > > > > Changelog: > > v6: > > * Based on "dma-debug: don't enforce dma mapping check on noncoherent > > allocations" patch. > > * Removed some unused variables from kmsan conversion. > > * Fixed missed ! in dma check. > > v5: https://lore.kernel.org/all/cover.1756822782.git.leon@kernel.org > > * Added Jason's and Keith's Reviewed-by tags > > * Fixed DMA_ATTR_MMIO check in dma_direct_map_phys > > * Jason's cleanup suggestions > > v4: https://lore.kernel.org/all/cover.1755624249.git.leon@kernel.org/ > > * Fixed kbuild error with mismatch in kmsan function declaration due to > > rebase error. > > v3: https://lore.kernel.org/all/cover.1755193625.git.leon@kernel.org > > * Fixed typo in "cacheable" word > > * Simplified kmsan patch a lot to be simple argument refactoring > > v2: https://lore.kernel.org/all/cover.1755153054.git.leon@kernel.org > > * Used commit messages and cover letter from Jason > > * Moved setting IOMMU_MMIO flag to dma_info_to_prot function > > * Micro-optimized the code > > * Rebased code on v6.17-rc1 > > v1: https://lore.kernel.org/all/cover.1754292567.git.leon@kernel.org > > * Added new DMA_ATTR_MMIO attribute to indicate > > PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path. > > * Rewrote dma_map_* functions to use thus new attribute > > v0: https://lore.kernel.org/all/cover.1750854543.git.leon@kernel.org/ > > ------------------------------------------------------------------------ > > > > This series refactors the DMA mapping to use physical addresses > > as the primary interface instead of page+offset parameters. This > > change aligns the DMA API with the underlying hardware reality where > > DMA operations work with physical addresses, not page structures. > > > > The series maintains export symbol backward compatibility by keeping > > the old page-based API as wrapper functions around the new physical > > address-based implementations. > > > > This series refactors the DMA mapping API to provide a phys_addr_t > > based, and struct-page free, external API that can handle all the > > mapping cases we want in modern systems: > > > > - struct page based cacheable DRAM > > - struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cacheable > > MMIO > > - struct page-less PCI peer to peer non-cacheable MMIO > > - struct page-less "resource" MMIO > > > > Overall this gets much closer to Matthew's long term wish for > > struct-pageless IO to cacheable DRAM. The remaining primary work would > > be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on > > phys_addr_t without a struct page. > > > > The general design is to remove struct page usage entirely from the > > DMA API inner layers. For flows that need to have a KVA for the > > physical address they can use kmap_local_pfn() or phys_to_virt(). This > > isolates the struct page requirements to MM code only. Long term all > > removals of struct page usage are supporting Matthew's memdesc > > project which seeks to substantially transform how struct page works. > > > > Instead make the DMA API internals work on phys_addr_t. Internally > > there are still dedicated 'page' and 'resource' flows, except they are > > now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both > > flows use the same phys_addr_t. > > > > When DMA_ATTR_MMIO is specified things work similar to the existing > > 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), > > pfn_valid(), etc are never called on the phys_addr_t. This requires > > rejecting any configuration that would need swiotlb. CPU cache > > flushing is not required, and avoided, as ATTR_MMIO also indicates the > > address have no cacheable mappings. This effectively removes any > > DMA API side requirement to have struct page when DMA_ATTR_MMIO is > > used. > > > > In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, > > except on the common path of no cache flush, no swiotlb it never > > touches a struct page. When cache flushing or swiotlb copying > > kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU > > usage. This was already the case on the unmap side, now the map side > > is symmetric. > > > > Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users > > must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA > > path must also set it. This corrects some existing bugs where iommu > > mappings for P2P MMIO were improperly marked IOMMU_CACHE. > > > > Since ATTR_MMIO is made to work with all the existing DMA map entry > > points, particularly dma_iova_link(), this finally allows a way to use > > the new DMA API to map PCI P2P MMIO without creating struct page. The > > VFIO DMABUF series demonstrates how this works. This is intended to > > replace the incorrect driver use of dma_map_resource() on PCI BAR > > addresses. > > > > This series does the core code and modern flows. A followup series > > will give the same treatment to the legacy dma_ops implementation. > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it > works fine in linux-next. Thanks a lot. > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > >
On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote: > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote: > > > > > > This series does the core code and modern flows. A followup series > > > will give the same treatment to the legacy dma_ops implementation. > > > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it > > works fine in linux-next. > > Thanks a lot. Just fyi, when dma debug is enabled, we're seeing this new warning below. I have not had a chance to look into it yet, so I'm just reporting the observation. DMA-API: nvme 0006:01:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: kernel/dma/debug.c:598 at add_dma_entry+0x26c/0x328, CPU#1: (udev-worker)/773 Modules linked in: acpi_power_meter(E) loop(E) efivarfs(E) autofs4(E) CPU: 1 UID: 0 PID: 773 Comm: (udev-worker) Tainted: G E N 6.17.0-rc6-next-20250918-debug #6 PREEMPT(none) Tainted: [E]=UNSIGNED_MODULE, [N]=TEST pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : add_dma_entry+0x26c/0x328 lr : add_dma_entry+0x26c/0x328 sp : ffff80009fe0f460 x29: ffff80009fe0f470 x28: 0000000000000001 x27: 0000000000000001 x26: ffff8000835d7f38 x25: ffff8000835d7000 x24: ffff8000835d7e60 x23: 0000000000000000 x22: 0000000006e2cc00 x21: 0000000000000000 x20: ffff800082e8f218 x19: ffff0000a908ff80 x18: 00000000ffffffff x17: ffff8000801972a0 x16: ffff800080197054 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000004 x12: 0000000000020006 x11: 0000000030e4ef9f x10: ffff800083443358 x9 : ffff80008019499c x8 : 00000000fffeffff x7 : ffff800083443358 x6 : 0000000000000000 x5 : 00000000000bfff4 x4 : 0000000000000000 x3 : ffff0000bb005ac0 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000bb005ac0 Call trace: add_dma_entry+0x26c/0x328 (P) debug_dma_map_phys+0xc4/0xf0 dma_map_phys+0xe0/0x410 dma_map_page_attrs+0x94/0xf8 blk_dma_map_direct.isra.0+0x64/0xb8 blk_rq_dma_map_iter_next+0x6c/0xc8 nvme_prep_rq+0x894/0xa98 nvme_queue_rqs+0xb0/0x1a0 blk_mq_dispatch_queue_requests+0x268/0x3b8 blk_mq_flush_plug_list+0x90/0x188 __blk_flush_plug+0x104/0x170 blk_finish_plug+0x38/0x50 read_pages+0x1a4/0x3b8 page_cache_ra_unbounded+0x1a0/0x400 force_page_cache_ra+0xa8/0xd8 page_cache_sync_ra+0xa0/0x3f8 filemap_get_pages+0x104/0x950 filemap_read+0xf4/0x498 blkdev_read_iter+0x88/0x180 vfs_read+0x214/0x310 ksys_read+0x70/0x110 __arm64_sys_read+0x20/0x30 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc4/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x1a0/0x340 el0t_64_sync_handler+0x98/0xe0 el0t_64_sync+0x17c/0x180 ---[ end trace 0000000000000000 ]---
On Fri, Sep 19, 2025 at 10:08:21AM -0600, Keith Busch wrote: > On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote: > > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote: > > > > > > > > This series does the core code and modern flows. A followup series > > > > will give the same treatment to the legacy dma_ops implementation. > > > > > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it > > > works fine in linux-next. > > > > Thanks a lot. > > Just fyi, when dma debug is enabled, we're seeing this new warning > below. I have not had a chance to look into it yet, so I'm just > reporting the observation. Did you apply all patches or only Marek's branch? I don't get this warning when I run my NVMe tests on current dmabuf-vfio branch. Thanks > > DMA-API: nvme 0006:01:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported > WARNING: kernel/dma/debug.c:598 at add_dma_entry+0x26c/0x328, CPU#1: (udev-worker)/773 > Modules linked in: acpi_power_meter(E) loop(E) efivarfs(E) autofs4(E) > CPU: 1 UID: 0 PID: 773 Comm: (udev-worker) Tainted: G E N 6.17.0-rc6-next-20250918-debug #6 PREEMPT(none) > Tainted: [E]=UNSIGNED_MODULE, [N]=TEST > pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) > pc : add_dma_entry+0x26c/0x328 > lr : add_dma_entry+0x26c/0x328 > sp : ffff80009fe0f460 > x29: ffff80009fe0f470 x28: 0000000000000001 x27: 0000000000000001 > x26: ffff8000835d7f38 x25: ffff8000835d7000 x24: ffff8000835d7e60 > x23: 0000000000000000 x22: 0000000006e2cc00 x21: 0000000000000000 > x20: ffff800082e8f218 x19: ffff0000a908ff80 x18: 00000000ffffffff > x17: ffff8000801972a0 x16: ffff800080197054 x15: 0000000000000000 > x14: 0000000000000000 x13: 0000000000000004 x12: 0000000000020006 > x11: 0000000030e4ef9f x10: ffff800083443358 x9 : ffff80008019499c > x8 : 00000000fffeffff x7 : ffff800083443358 x6 : 0000000000000000 > x5 : 00000000000bfff4 x4 : 0000000000000000 x3 : ffff0000bb005ac0 > x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000bb005ac0 > Call trace: > add_dma_entry+0x26c/0x328 (P) > debug_dma_map_phys+0xc4/0xf0 > dma_map_phys+0xe0/0x410 > dma_map_page_attrs+0x94/0xf8 > blk_dma_map_direct.isra.0+0x64/0xb8 > blk_rq_dma_map_iter_next+0x6c/0xc8 > nvme_prep_rq+0x894/0xa98 > nvme_queue_rqs+0xb0/0x1a0 > blk_mq_dispatch_queue_requests+0x268/0x3b8 > blk_mq_flush_plug_list+0x90/0x188 > __blk_flush_plug+0x104/0x170 > blk_finish_plug+0x38/0x50 > read_pages+0x1a4/0x3b8 > page_cache_ra_unbounded+0x1a0/0x400 > force_page_cache_ra+0xa8/0xd8 > page_cache_sync_ra+0xa0/0x3f8 > filemap_get_pages+0x104/0x950 > filemap_read+0xf4/0x498 > blkdev_read_iter+0x88/0x180 > vfs_read+0x214/0x310 > ksys_read+0x70/0x110 > __arm64_sys_read+0x20/0x30 > invoke_syscall+0x4c/0x118 > el0_svc_common.constprop.0+0xc4/0xf0 > do_el0_svc+0x24/0x38 > el0_svc+0x1a0/0x340 > el0t_64_sync_handler+0x98/0xe0 > el0t_64_sync+0x17c/0x180 > ---[ end trace 0000000000000000 ]--- > >
On Sat, Sep 20, 2025 at 06:53:52PM +0300, Leon Romanovsky wrote: > On Fri, Sep 19, 2025 at 10:08:21AM -0600, Keith Busch wrote: > > On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote: > > > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote: > > > > > > > > > > This series does the core code and modern flows. A followup series > > > > > will give the same treatment to the legacy dma_ops implementation. > > > > > > > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it > > > > works fine in linux-next. > > > > > > Thanks a lot. > > > > Just fyi, when dma debug is enabled, we're seeing this new warning > > below. I have not had a chance to look into it yet, so I'm just > > reporting the observation. > > Did you apply all patches or only Marek's branch? > I don't get this warning when I run my NVMe tests on current dmabuf-vfio branch. This was the snapshot of linux-next from the 20250918 tag. It doesn't have the full patchset applied. One other thing to note, this was runing on arm64 platform using smmu configured with 64k pages. If your iommu granule is 4k instead, we wouldn't use the blk_dma_map_direct path.
On Sat, Sep 20, 2025 at 06:47:27PM -0600, Keith Busch wrote: > On Sat, Sep 20, 2025 at 06:53:52PM +0300, Leon Romanovsky wrote: > > On Fri, Sep 19, 2025 at 10:08:21AM -0600, Keith Busch wrote: > > > On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote: > > > > On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote: > > > > > > > > > > > > This series does the core code and modern flows. A followup series > > > > > > will give the same treatment to the legacy dma_ops implementation. > > > > > > > > > > Applied patches 1-13 into dma-mapping-for-next branch. Let's check if it > > > > > works fine in linux-next. > > > > > > > > Thanks a lot. > > > > > > Just fyi, when dma debug is enabled, we're seeing this new warning > > > below. I have not had a chance to look into it yet, so I'm just > > > reporting the observation. > > > > Did you apply all patches or only Marek's branch? > > I don't get this warning when I run my NVMe tests on current dmabuf-vfio branch. > > This was the snapshot of linux-next from the 20250918 tag. It doesn't > have the full patchset applied. > > One other thing to note, this was runing on arm64 platform using smmu > configured with 64k pages. If your iommu granule is 4k instead, we > wouldn't use the blk_dma_map_direct path. I spent some time looking to see if I could guess what this is and came up empty. It seems most likely we are leaking a dma mapping tracking somehow? The DMA API side is pretty simple here though.. Not sure the 64k/4k itself is a cause, but triggering the non-iova flow is probably the issue. Can you check the output of this debugfs: /* * Dump mappings entries on user space via debugfs */ static int dump_show(struct seq_file *seq, void *v) ? If the system is idle and it has lots of entries that is probably confirmation of the theory. Jason
On Tue, Sep 23, 2025 at 02:09:36PM -0300, Jason Gunthorpe wrote: > On Sat, Sep 20, 2025 at 06:47:27PM -0600, Keith Busch wrote: > > > > One other thing to note, this was runing on arm64 platform using smmu > > configured with 64k pages. If your iommu granule is 4k instead, we > > wouldn't use the blk_dma_map_direct path. > > I spent some time looking to see if I could guess what this is and > came up empty. It seems most likely we are leaking a dma mapping > tracking somehow? The DMA API side is pretty simple here though.. Yeah, nothing stood out to me here either. > Not sure the 64k/4k itself is a cause, but triggering the non-iova > flow is probably the issue. > > Can you check the output of this debugfs: I don't have a system in this state at the moment, so we checked previous logs on machines running older kernels. It's extermely uncommon, but this error was happening prior to this series, so I don't think this introduced any new problem here. I'll keeping looking, but I don't think we'll make much progress if I can't find a more reliable reproducer. Thanks!
On Tue, Sep 23, 2025 at 12:30:55PM -0600, Keith Busch wrote: > I don't have a system in this state at the moment, so we checked > previous logs on machines running older kernels. It's extermely > uncommon, but this error was happening prior to this series, so I don't > think this introduced any new problem here. I'll keeping looking, but I > don't think we'll make much progress if I can't find a more reliable > reproducer. Okay, that's great. It needs to get resolved but it is not this series at fault. Very rare is a different perspective, I mis-thought it was happening reproducible all the time.. It seems to me it is actually a legitimate thing for userspace to be able to trigger this cache line debug. If you do concurrent O_DIRECT to the very same memory it should trigger if I read it right.. So it may not even be an actual bug??? Jason
On Tue, Sep 23, 2025 at 07:22:16PM -0300, Jason Gunthorpe wrote: > Very rare is a different perspective, I mis-thought it was happening > reproducible all the time.. Yes, sorry for the false alarm. I think we got unlucky and hit it on one of the first boots from testing linux-next, so knee-jerk reaction was to suspect the new code that showed up in the stack.
© 2016 - 2025 Red Hat, Inc.