Re: [PATCH] dma-debug: skip cacheline overlap tracking on cache-coherent architectures

[Leon Romanovsky <leon@kernel.org>]

On Mon, May 18, 2026 at 04:32:51PM +0500, Mikhail Gavrilov wrote:
> The dma-debug cacheline overlap tracking emits two distinct warnings
> when multiple DMA mappings share a cacheline:
> 
>   1. add_dma_entry() calls err_printk("cacheline tracking EEXIST,
>      overlapping mappings aren't supported\n") on every -EEXIST from
>      active_cacheline_insert().
> 
>   2. active_cacheline_inc_overlap() calls WARN_ONCE("exceeded %d
>      overlapping mappings of cacheline %pa\n", ...) when the 3-bit
>      per-cacheline overlap counter in the dma_active_cacheline radix
>      tree would saturate past ACTIVE_CACHELINE_MAX_OVERLAP (= 7).
> 
> Commit 3d48c9fd78dd ("dma-debug: suppress cacheline overlap warning
> when arch has no DMA alignment requirement") suppressed (1) on
> architectures where hardware bus snooping makes cacheline-overlapping
> DMA mappings safe.  The same reasoning applies to (2): the tracking is
> pure overhead on those architectures, and (2) still fires under real
> workloads, e.g. heavy NVMe block I/O on x86_64:
> 
>   DMA-API: exceeded 7 overlapping mappings of cacheline 0x...
>   WARNING: kernel/dma/debug.c:465 at add_dma_entry+0x394/0x410
>   Call Trace:
>    add_dma_entry+...
>    debug_dma_map_phys+...
>    dma_map_phys+...
>    blk_dma_map_iter_start+...
>    nvme_map_data+...
> 
> The block layer routinely produces nine or more concurrent in-flight
> mappings whose buffers share a single cacheline.  On hardware-coherent
> systems this is harmless, but it saturates the tag-based overlap
> counter and produces a splat indistinguishable from a real driver bug.
> 
> Extend the gate to skip the cacheline overlap tracking entirely on
> cache-coherent architectures, mirroring the DMA_TO_DEVICE early-return
> that already exists for the same "tracking is unnecessary" reason.  The
> helper dma_debug_cacheline_tracking_needed() captures the condition and
> is symmetric to the existing add_dma_entry() check.
> 
> The same DMA_BOUNCE_UNALIGNED_KMALLOC + SWIOTLB suppression that
> commit 03521c892bb8 ("dma-debug: don't report false positives with
> DMA_BOUNCE_UNALIGNED_KMALLOC") added to (1) applies here for the same
> reason: unaligned kmalloc buffers are bounced through aligned swiotlb
> buffers, so the original cacheline overlap never reaches DMA.  The
> helper preserves both suppression conditions.
> 
> Reproducer (out-of-tree module): map a single 8-byte buffer with
> dma_map_single(..., DMA_BIDIRECTIONAL) nine times in a row.  The 9th
> call deterministically fires the WARN_ONCE on an unfixed kernel; with
> this patch applied no warning is emitted regardless of the number of
> overlapping mappings.

I would say this reproducer is incorrect. From what I recall, the only two
legitimate use cases for cacheline overlap are virtio and RDMA. The first
intentionally relies on it for small allocations, and the second exports the
cachelines to the user space and cannot operate on non‑coherent architectures.

Thanks