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. 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. It should only be used by callers like RDMA/DRM/etc where they have historical uAPI that has never supported incoherent DMA operation and are an exception to the normal DMA API requirements. The problem is to limit the use of that flag to only a few approved places. I fear adding such a flag wide open would open the door to widespread driver abuse. These days we have 'export symbol for module' so maybe there is a way to do it with safety? I'd really like this right now because CC systems are forcing SWIOTLB and things like RDMA userspace are unfixably broken with SWIOTLB. The uAPI it has simply cannot work with it. I'd much rather to immediate fail than suffer data corruption. Jiri was looking at adding some hacky "is cc" check, but I'd far prefer a proper flag that covered all the uAPI breaking cases. Jason
