Hi Leon, On 18.03.2026 09:18, Leon Romanovsky wrote: > On Wed, Mar 18, 2026 at 09:03:00AM +0100, Marek Szyprowski wrote: >> 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().
Okay, I will merge all patches to the -fixes branch then. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
