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

[Mikhail Gavrilov]

On Tue, May 19, 2026 at 2:06 PM David Laight
<david.laight.linux@xxxxxxxxx> wrote:
>
> Isn't there a flag to kmalloc() that indicates the buffers will be used
> for dma and mustn't share a cache line with anything else writable.
> (Which means the size must be rounded up to a multiple of the cache
> line size.)

Not a per-call flag, but ARCH_KMALLOC_MINALIGN does it at compile
time: when set to cache-line size (as it traditionally is on
non-coherent arches), kmalloc returns cache-line-aligned buffers so
independent kmalloc allocations can't share a cacheline.

CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC (370645f41e6e) was added to allow
smaller kmalloc minimums on those arches by bouncing small unaligned
DMA mappings through SWIOTLB; this patch preserves the cacheline
tracking when that bounce path is active.

What still hits the WARN isn't independent allocations sharing a
cacheline -- those are already prevented above. It's:
- the same buffer used in multiple concurrent DMA mappings (raid1
sync, io_uring iopoll buffer reuse, dm-thin, ...)
- userspace DIO buffers, where kmalloc alignment doesn't apply

> For DMA_FROM_DEVICE it is important that the cpu doesn't dirty the cache
> lines.

Right -- that's the real corruption concern on non-coherent arches and
why the WARN keeps firing there with this patch. On coherent arches
bus snooping handles it, which is the scope of the suppression.

> This is probably worse on systems with 256 byte cache lines.

Mechanically yes, but those systems size ARCH_KMALLOC_MINALIGN to
match, so kmalloc allocations still don't overlap each other. The
remaining cases (shared buffers, DIO) are what Christoph is looking at
via the DIO-path alignment requirement.

-- 
Thanks,
Mikhail