From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73BD0346AF0 for ; Sun, 8 Mar 2026 23:09:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773011361; cv=none; b=PM46vyzFedjYFpxdbQjyMjwxZmMpa+yQRFI6N60gjq08xM2j5OpMynjRn5iRmpLn/KTpfLq2wKQQqhcXjOm+7/NqXl5AosHOL1MLjEyifPc1X2kQiK//nWEvUBoJj/qeVUXnREuo2hWjE5C1kMNVOxnGK9tzrmafhtJXBK3JBtQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773011361; c=relaxed/simple; bh=rBbx3d93p2y2jIh4G2U5Gu80cWTEuOIfSXCGSgCzVU0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sbQayRvYvRQILp1NPoO2rwlTV4xaHgPe+IC+b+Pl7cUigYrpExYT258Hpy7mFIEyMh6Q1qByzdomJVhdkHGNCn19iDrI364sfFhfHoopuxlZMRh3WAQL4zQR8tfuyvC+zpwiAniqSqALb8kxe/JWxNIhziUxss8LH/Aosrrm7uk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=VG5XLHyw; arc=none smtp.client-ip=209.85.160.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="VG5XLHyw" Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-506a6cf8242so81217341cf.1 for ; Sun, 08 Mar 2026 16:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1773011359; x=1773616159; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aJUOBkP/5JQJnNKHejLcwjpKdPk3k1pSv7xveepfvi0=; b=VG5XLHywQc9Gws5ePKS1MUsQEqYQuMj40HD3KNtw+Pth6/fCC45oSpQhz2/Al4NsM/ BC2cmgo33MuGVIOhlNpUvYKkhufDc1x6J2MfwSMP6Iw2PYQGKrYliMe3UvxmVJSsCWup 6BJruFUt6EXdmUuSi5i3V7Krsf0BQGBCdgW1+yZnCzEOQIOQvQQlyvW1r8G3LblZfqe1 S6m+D2RlyRl4u50hn2fqpu7yPIX4aaT1K+xgigByFL87JmyWNE5aoZvKuxJiFgVG61tV b3hDJkZ54oKcRa30Eeo53XGXCHVAFSvw0xhZXI3mT5/zqECF8LIAtjpwOxOhOIxIUoWb 8kIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773011359; x=1773616159; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aJUOBkP/5JQJnNKHejLcwjpKdPk3k1pSv7xveepfvi0=; b=IiANf950dGF65C9G4D9MjkO41Zr3F6z/eATBlZ+D6WRgvWH0Hzkh+pwMuWqW2iZOZH uUc/FtVq3tTGxQH5fVJnlCHjABbwA47cy54xcofrwAna/RLLTFF+O2cfqaK8CdRTzns1 VOkdXrbPWhhbMoLsprAAyAX2IT9/BgFdO+0CrFBi+9k0sm/mDzy7BnJtvXBfan1zKybb bhfpvFuRI9XAzgWaocEf7uUz0r4FEwVBaRgzjvZNNTRanWwNlJKOplUQk0mt9p3PT0zT vsVWadMBU/2DjTYf+m8uMT2AJh5dIk7sAk/CfD87wKjl33XHmLJTDKW2+1lIWcx4lcC6 n0BA== X-Forwarded-Encrypted: i=1; AJvYcCVAqXucYldWvvhRFAdlTjGZ7AI2vjpYlqHqPyZ/AJ/1JcsF0WKdYBXBPcQMg7Bb3+fndmKocpSQiok=@vger.kernel.org X-Gm-Message-State: AOJu0YzmsTn5Ibe5wBlT+jp+4y49oMJyRC2CNCJ+vSrN1rHpuDGkYdx+ EWj7I4W76VxedOKbAIsbdm1jR6MZRdiGoAHTpzi/jkRDmVA6Jg7DUab4CYEtziP2U5Iy2v7Ct70 bcjiy X-Gm-Gg: ATEYQzzsbKwFe2hxNnoe21wJGIj13lfbC7cBOkSmKyVjvdjhHwLX+OHaDyu8fE2Zn1G UQZn8ClzyESaQYbcZz+3HrPAun1T3jLTI4wmP6P5U17uRtXb3mslHXUhGVQKK2ptExaei7EQ3Ae eWgMqqr2vxtrLzn+ZxxmaLZ/XuCqKLNGC2Gv1O5WFpjRVMAnkeqYpyQIwedK/2Ybcy8ZX8e5Rly RH6DNBoAu3yNUlYYqy3PWXNMWXZSDAQGKzd1NH5Whoo/2XvkoF+giDMqXYp0W14Uf4YVB00Ah9A q40AOQ4xW+BduMEj3P8ry1VRJAAbdBGQmBu1vv1RTwjazCsxNed9eQmW9TbDL13WcxGhZgBwkCj hj3xG2tfD18dt2uouth+ZP5dhDEIa7RQtNObMPU9Zgeq2hpdfYoBylqZlYRH6KkWOE2kcKefDak V+Pp/uhskZf1FNCXfebS0BGNpKHoG0nLIksgi3d96EDOFoRBybGtBsPjNHDKNVze4amRkbif28m Njk9rUR X-Received: by 2002:a05:622a:1995:b0:509:127d:ee06 with SMTP id d75a77b69052e-509127df85cmr39687201cf.58.1773011359286; Sun, 08 Mar 2026 16:09:19 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-508f66da77csm51473791cf.30.2026.03.08.16.09.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 16:09:18 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vzNFM-0000000Bzue-3rG7; Sun, 08 Mar 2026 20:09:16 -0300 Date: Sun, 8 Mar 2026 20:09:16 -0300 From: Jason Gunthorpe To: Leon Romanovsky Cc: Marek Szyprowski , Robin Murphy , "Michael S. Tsirkin" , Petr Tesarik , Jonathan Corbet , Shuah Khan , Jason Wang , Xuan Zhuo , Eugenio =?utf-8?B?UMOpcmV6?= , 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 Message-ID: <20260308230916.GI1687929@ziepe.ca> References: <20260307-dma-debug-overlap-v1-0-c034c38872af@nvidia.com> <20260307-dma-debug-overlap-v1-2-c034c38872af@nvidia.com> <20260308181920.GH1687929@ziepe.ca> <20260308184902.GR12611@unreal> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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