Re: [PATCH 2/3] dma-mapping: Clarify valid conditions for CPU cache line overlap

[Leon Romanovsky <leon@kernel.org>]

On Sun, Mar 08, 2026 at 08:09:16PM -0300, Jason Gunthorpe wrote:
> On Sun, Mar 08, 2026 at 08:49:02PM +0200, Leon Romanovsky wrote:
> > On Sun, Mar 08, 2026 at 03:19:20PM -0300, Jason Gunthorpe wrote:
> > > On Sat, Mar 07, 2026 at 06:49:56PM +0200, Leon Romanovsky wrote:
> > > 
> > > > -This attribute indicates the CPU will not dirty any cacheline overlapping this
> > > > -DMA_FROM_DEVICE/DMA_BIDIRECTIONAL buffer while it is mapped. This allows
> > > > -multiple small buffers to safely share a cacheline without risk of data
> > > > -corruption, suppressing DMA debug warnings about overlapping mappings.
> > > > -All mappings sharing a cacheline should have this attribute.
> > > > +DMA_ATTR_CPU_CACHE_OVERLAP
> > > 
> > > This is a very specific and well defined use case that allows some cache
> > > flushing behaviors to work only under the promise that the CPU doesn't
> > > touch the memory to cause cache inconsistencies.
> > > 
> > > > +Another valid use case is on systems that are CPU-coherent and do not use
> > > > +SWIOTLB, where the caller can guarantee that no cache maintenance operations
> > > > +(such as flushes) will be performed that could overwrite shared cache lines.
> > > 
> > > This is something completely unrelated. 
> > 
> > I disagree. The situation is equivalent in that callers guarantee the
> > CPU cache will not be overwritten.
> 
> The RDMA callers do no such thing, they just don't work at all if
> there is non-coherence in the mapping which is why it is not a bug.
> 
> virtio looks like it does actually keep the caches clean for different
> mappings (and probably also in practice forced coherent as well given
> qemu is coherent with the VM and VFIO doesn't allow non-coherent DMA
> devices)
> 
> > > What I would really like is a new DMA_ATTR_REQUIRE_COHERENT which
> > > fails any mappings requests that would use any SWIOTLB or cache
> > > flushing.
> > 
> > You are proposing something orthogonal that operates at a different layer
> > (DMA mapping). However, for DMA debugging, your new attribute will be
> > equivalent to DMA_ATTR_CPU_CACHE_OVERLAP.
> 
> DMA_ATTR is a dma mapping flag, if you want some weird dma debugging
> flag it should be called DMA_ATTR_DEBUGGING_IGNORE_CACHELINES with
> some kind of statement at the user why it is OK.

And this is the issue: the existing DMA_ATTR_CPU_CACHE_CLEAN is essentially
a debug-oriented attribute. The upper layers are already handled through
__dma_from_device_group_begin()/end(), which pad cache lines on
non-coherent systems.

Marek,

What do you see as the right path forward here? RDMA has a legitimate use
case where CPU cache lines may overlap. The underlying reason differs from
VirtIO, but the outcome is the same. Should I keep the current name? Should
we rename it to the proposed DMA_ATTR_CPU_CACHE_OVERLAP or
DMA_ATTR_DEBUGGING_IGNORE_CACHELINES? Should we introduce a new
DMA_ATTR_REQUIRE_COHERENT attribute instead? Or do you have another
recommendation?

Thanks

> 
> Jason