From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 C4A41184 for ; Thu, 12 Mar 2026 12:19:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773317982; cv=none; b=U/PXODIcYEwg91Exc+8zMkaG3lN8iWQlKNql//90mHGAtskM96ta5Bx+rICKgTksaAXmD4JxYwDKiCuZp0vCwGXEBY4wN/XVgiUkyNdKEWScsuRZkitw3fCx83Eh806w8N0KVgxl+tAwSnTN/qE791B2sKXBLxwi1Tsd/39GNwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773317982; c=relaxed/simple; bh=Oj/7ehc0cCCCDQU/7pS4vL4fF7AXLJnL/YyNxYgW3Og=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VEVaGulSccxCh9sSHv3LWr1nVjKuP0PGMzZ4kY9xeJND6f3rcsu1rDyEaVYbuMPUGkMCAaadKsuq90AmxY0U7lwsk5u5O3rxMNZwXVL62u5UlFxI/IGp9a2/E4DTF5TwYiyXImaxZARKhISCjx4mZN0Ou2PYaCdEa4iZe64kk0c= 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=BKS8aTvx; arc=none smtp.client-ip=209.85.222.175 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="BKS8aTvx" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-8cd8576a512so215180085a.0 for ; Thu, 12 Mar 2026 05:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1773317980; x=1773922780; 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=0lXptsQPO/2bR1nDOk4C8coAYtgdswQIgAW2nY2lBKk=; b=BKS8aTvxZ3yh3IKjkSO1betRitYvAMjkK4YVAlshSXkv+ZnnBOXn7O7vaa1xC/RfHE zkAT2IkDbxusmUdQBc03On3Qiajg5+h3X3muwby/ijTjxLZBSm5SYsOa7xok8BrqH3LN GLFLO/42YieyVkWFv+HoGj95X8UG3+cuKr33MM8HWMqACq0QTUPGEYEcq/UsSdyMbSFX GAifEack/sIllT9LxthUXMJMeOlziVtcG2Ljouz+6y6o8KqRsAM6HTyboxZrtMUgzNsk RMbV/Q6WtRTyCeZUGeROzDdlUhO5p8muQs9pa4NEB7B0le9KZsotXJ3Ii6ruCleOy2Ub FnMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773317980; x=1773922780; 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=0lXptsQPO/2bR1nDOk4C8coAYtgdswQIgAW2nY2lBKk=; b=YYu+48eWghQf6GI48FpzIpCNHYNS9VTozrDcBb1nKu7bMZ/VrxHCe+8v63dqFb2QA+ mgGh69TCh7NdeCpcZzFVhiDiPWCZoOJuscufBPOTQAwmG7OYy7/vPWOFCdwFoXwrellb 76gppU9Bi0/xLxjndXlP8vv32KrAwcEyf3D7io9vRKzJc/l9geLfvx5ekgr2JTBs0D8F 0f2e9uCOx18b9fGHXc+VNO1M83bwDyQ4n9TSAvC/WxW3+ntsFC16VWr1HvuRikFuVF45 GuPXHXv5Ic3XJkcLsXkD2pWmfxAa57C1HX84bc8hGCN5Hl+g+BKom48bc73Ow9B7SKsZ MxHw== X-Forwarded-Encrypted: i=1; AJvYcCV8VTF8RnRY0J7TVO9FkFhcYPBtqJyi7KH7bwc1RRjU8lQiD1PuAKWBiI9jwoB+nGp0y7VjtZkpLLehf9o=@vger.kernel.org X-Gm-Message-State: AOJu0YwTD4PCIXLKBwew9AX8Yaz+RqFzZjB8poCAK4g/jd4nfJ6msM1f h8A5DdvRSc+SfQb5NUVZW10G6sS1NTVa6FTeH/TnLBqWXK+1c60KFY52Xz4Brjs82ao= X-Gm-Gg: ATEYQzyuV9JrOLmogti1EADSZg13WjnWZHKEEVIK//ioXbBkmlxYcccEfCPkJZfyrOZ cQSEE09J3eifwOus6utGavEmHE3nWVc5Tch9OCQaTS1Z9P/JYMkxIk/m5X596Jdwt1J+lxqooiX pKlQxcI6zsS6nAwEPgMqCw48Wdz3baZ+HGOkO7N/g5Cyw0+Y55wPONZp7CWt6gKwwnYUGFDBF5Y oGyqFtgfmmWYSprLmRl31L7vsPh70lbcIry9UIBJesOGqD57RJPbDXfClPwFRJdBnfPrprspTLV ZdzRIWbvkyfXRnvWfxznXDJYfwanpFXv03vwBRACnzMfdeJS99QHcnfdQaw9sFS/0ptW7PdXW+A v5fzspn7mW/E/oNdNR2aMA2HfBOqAQFgEcfC5CujgthQ8Mjt0ZSF9IpWtA5L04JgXk9C8xT+KxZ AjVUiHMd1nALj3kt5myTfQTQPvfCQqQgNgqtUn3WgnVlugw/8oNdTXsaWB3Pm+HTv2s97Sl7EjQ 2de+aWE X-Received: by 2002:a05:620a:4041:b0:8c7:3ff0:d472 with SMTP id af79cd13be357-8cdaa7b6b03mr382866785a.15.1773317979843; Thu, 12 Mar 2026 05:19:39 -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 af79cd13be357-8cda21346a0sm321675885a.34.2026.03.12.05.19.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 05:19:38 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1w0f0r-00000006esN-1WXU; Thu, 12 Mar 2026 09:19:37 -0300 Date: Thu, 12 Mar 2026 09:19:37 -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?= , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Joerg Roedel , Will Deacon , Andrew Morton , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, virtualization@lists.linux.dev, linux-rdma@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 4/8] dma-mapping: Introduce DMA require coherency attribute Message-ID: <20260312121937.GD1469476@ziepe.ca> References: <20260311-dma-debug-overlap-v2-0-e00bc2ca346d@nvidia.com> <20260311-dma-debug-overlap-v2-4-e00bc2ca346d@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@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: <20260311-dma-debug-overlap-v2-4-e00bc2ca346d@nvidia.com> On Wed, Mar 11, 2026 at 09:08:47PM +0200, Leon Romanovsky wrote: > From: Leon Romanovsky > > The mapping buffers which carry this attribute require DMA coherent system. > This means that they can't take SWIOTLB path, can perform CPU cache overlap > and doesn't perform cache flushing. > > Signed-off-by: Leon Romanovsky > --- > Documentation/core-api/dma-attributes.rst | 12 ++++++++++++ > include/linux/dma-mapping.h | 7 +++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/debug.c | 3 ++- > kernel/dma/mapping.c | 6 ++++++ > 5 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst > index 48cfe86cc06d7..69d094f144c70 100644 > --- a/Documentation/core-api/dma-attributes.rst > +++ b/Documentation/core-api/dma-attributes.rst > @@ -163,3 +163,15 @@ data corruption. > > All mappings that share a cache line must set this attribute to suppress DMA > debug warnings about overlapping mappings. > + > +DMA_ATTR_REQUIRE_COHERENT > +------------------------- > + > +The mapping buffers which carry this attribute require DMA coherent system. This means > +that they can't take SWIOTLB path, can perform CPU cache overlap and doesn't perform > +cache flushing. DMA mapping requests with the DMA_ATTR_REQUIRE_COHERENT fail on any system where SWIOTLB or cache management is required. This should only be used to support uAPI designs that require continuous HW DMA coherence with userspace processes, for example RDMA and DRM. At a minimum the memory being mapped must be userspace memory from pin_user_pages() or similar. Drivers should consider using dma_mmap_pages() instead of this interface when building their uAPIs, when possible. It must never be used in an in-kernel driver that only works with kernal memory. > @@ -164,6 +164,9 @@ dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys, size_t size, > if (WARN_ON_ONCE(!dev->dma_mask)) > return DMA_MAPPING_ERROR; > > + if (!dev_is_dma_coherent(dev) && (attrs & DMA_ATTR_REQUIRE_COHERENT)) > + return DMA_MAPPING_ERROR; This doesn't capture enough conditions.. is_swiotlb_force_bounce(), dma_kmalloc_needs_bounce(), dma_capable(), etc all need to be blocked too So check it inside swiotlb_map() too, and maybe shift the above into the existing branches: if (!dev_is_dma_coherent(dev) && !(attrs & (DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MMIO))) arch_sync_dma_for_device(phys, size, dir); Jason