From: Jason Gunthorpe <jgg@ziepe.ca>
To: Leon Romanovsky <leon@kernel.org>
Cc: "Marek Szyprowski" <m.szyprowski@samsung.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Petr Tesarik" <ptesarik@suse.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, virtualization@lists.linux.dev,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH 2/3] dma-mapping: Clarify valid conditions for CPU cache line overlap
Date: Sun, 8 Mar 2026 20:09:16 -0300 [thread overview]
Message-ID: <20260308230916.GI1687929@ziepe.ca> (raw)
In-Reply-To: <20260308184902.GR12611@unreal>
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.
Jason
next prev parent reply other threads:[~2026-03-08 23:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 16:49 [PATCH 0/3] RDMA: Enable runs with DMA debug enabled Leon Romanovsky
2026-03-07 16:49 ` [PATCH 1/3] dma-debug: Allow multiple invocations of overlapping entries Leon Romanovsky
2026-03-07 16:49 ` [PATCH 2/3] dma-mapping: Clarify valid conditions for CPU cache line overlap Leon Romanovsky
2026-03-08 18:19 ` Jason Gunthorpe
2026-03-08 18:49 ` Leon Romanovsky
2026-03-08 23:09 ` Jason Gunthorpe [this message]
2026-03-09 9:03 ` Leon Romanovsky
2026-03-09 12:30 ` Marek Szyprowski
2026-03-09 13:20 ` Jason Gunthorpe
2026-03-09 15:05 ` Leon Romanovsky
2026-03-09 15:13 ` Jason Gunthorpe
2026-03-10 9:45 ` Marek Szyprowski
2026-03-10 12:34 ` Jason Gunthorpe
2026-03-10 18:27 ` Leon Romanovsky
2026-03-10 21:08 ` Marek Szyprowski
2026-03-10 23:34 ` Jason Gunthorpe
2026-03-07 16:49 ` [PATCH 3/3] RDMA/umem: Tell DMA debug that cacheline overlap is expected Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260308230916.GI1687929@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=corbet@lwn.net \
--cc=eperezma@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=leon@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mst@redhat.com \
--cc=ptesarik@suse.com \
--cc=robin.murphy@arm.com \
--cc=skhan@linuxfoundation.org \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox