Re: [PATCH v3 0/8] RDMA: Enable operation with DMA debug enabled

Leon Romanovsky
2026-03-18T08:19:08Z

On Wed, Mar 18, 2026 at 09:03:00AM +0100, Marek Szyprowski wrote:
> Hi Leon,
>
> On 17.03.2026 20:05, Leon Romanovsky wrote:
> > On Mon, Mar 16, 2026 at 09:06:44PM +0200, Leon Romanovsky wrote:
> >> Add a new DMA_ATTR_REQUIRE_COHERENT attribute to the DMA API to mark
> >> mappings that must run on a DMA‑coherent system. Such buffers cannot
> >> use the SWIOTLB path, may overlap with CPU caches, and do not depend on
> >> explicit cache flushing.
> >>
> >> Mappings using this attribute are rejected on systems where cache
> >> side‑effects could lead to data corruption, and therefore do not need
> >> the cache‑overlap debugging logic. This series also includes fixes for
> >> DMA_ATTR_CPU_CACHE_CLEAN handling.
> >> Thanks.
> > <...>
> >
> >> ---
> >> Leon Romanovsky (8):
> >> dma-debug: Allow multiple invocations of overlapping entries
> >> dma-mapping: handle DMA_ATTR_CPU_CACHE_CLEAN in trace output
> >> dma-mapping: Clarify valid conditions for CPU cache line overlap
> >> dma-mapping: Introduce DMA require coherency attribute
> >> dma-direct: prevent SWIOTLB path when DMA_ATTR_REQUIRE_COHERENT is set
> >> iommu/dma: add support for DMA_ATTR_REQUIRE_COHERENT attribute
> >> RDMA/umem: Tell DMA mapping that UMEM requires coherency
> >> mm/hmm: Indicate that HMM requires DMA coherency
> >>
> >> Documentation/core-api/dma-attributes.rst | 38 ++++++++++++++++++++++++-------
> >> drivers/infiniband/core/umem.c | 5 ++--
> >> drivers/iommu/dma-iommu.c | 21 +++++++++++++----
> >> drivers/virtio/virtio_ring.c | 10 ++++----
> >> include/linux/dma-mapping.h | 15 ++++++++----
> >> include/trace/events/dma.h | 4 +++-
> >> kernel/dma/debug.c | 9 ++++----
> >> kernel/dma/direct.h | 7 +++---
> >> kernel/dma/mapping.c | 6 +++++
> >> mm/hmm.c | 4 ++--
> >> 10 files changed, 86 insertions(+), 33 deletions(-)
> > Marek,
> >
> > Despite the "RDMA ..." tag in the subject, the diffstat clearly shows that
> > you are the appropriate person to take this patch.
>
> I plan to take the first 2 patches to the dma-mapping-fixes branch
> (v7.0-rc) and the next to dma-mapping-for-next. Should I also take the
> RDMA and HMM patches, or do You want a stable branch for merging them
> via respective subsystem trees?

I suggest taking all patches into the -fixes branch, as the "RDMA/..." patch
also resolves the dmesg splat. With -fixes, there is no need to worry about
a shared branch since we do not expect merge conflicts in that area.

If you still prefer to split the series between -fixes and -next, it would be
better to use a shared branch in that case. There are patches on the RDMA
list targeted for -next that touch ib_umem_get().

Thanks

>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>