From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (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 71317273D6D for ; Sun, 8 Mar 2026 18:19:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772993964; cv=none; b=cUimPm7cqz29OF5m2nZkh5AL5uPtRRu/QspL0LveHtsP1dvoVlw4JfrLJr4qp1Flzfo4foprEFS7OD9QJMZeopIG6gfvDO2d24KioJG5V/CxkmdCarinlX63f/TtE0hHgNnaNxuIH1g3L5Av5p8FcfokwBbA+BQKMX+bZvStJFU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772993964; c=relaxed/simple; bh=RFwQC+ynapVSJqHtn5HxtDxJR3xhkceo/7GA/6B7F8o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XhBnbJjj4XYb+I/g6fJD0QAehajVv/vknyi0nKtOSWDu/A6n1HtoibdBNg+tnIinLy+XEj+Gg32TlAfuLpQfQ5abSux1aj0mI87obVRYOmX93eaNwwohlxYsU+ua9GsrukZYj1RbxGcTDEhctdG35OuUph1hxyIV+0OcXZlKhJM= 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=NSnqhmW4; arc=none smtp.client-ip=209.85.160.179 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="NSnqhmW4" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-509101189edso6235801cf.3 for ; Sun, 08 Mar 2026 11:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1772993962; x=1773598762; 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=8l9HCiIJk8f6YJBdD7T3EgoBIxuKKvMDtuYccvH3ixY=; b=NSnqhmW4iChRXfe2lxZ7cshJTxxstp6S+yBIZcsp4Xk82pT2z6pheqN7RQMMHKBrCi g/pUtXqwZe/1lIyCFZoUqFeLyUryjPubE0qMegn7MrC8b1mHdhA0bReaQouYG5wf8ASg PRd1v4B4kbMPd8qB9JYc2AhZDRrvi5ULhlWmFX6xZr/JZ8bYa3+amMtn/lWIdq3JR3QH d80TfpbTF4mlT+vuxw9kW0YdD58LMesn/mEM8U/hfTucUpdhI23wqFFZD0iBUQmTcZkK pIpH7JInxVyHoaXEPHroaPNxqaxXFencPSbUD/hZ3iGtjgAhF/zeHFOWN8V08/fGZJFa n81A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772993962; x=1773598762; 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=8l9HCiIJk8f6YJBdD7T3EgoBIxuKKvMDtuYccvH3ixY=; b=MJYBtnBmcAeekjfX0pZhfdkTrcm+hCucEUrOXK9DV8eKv/AgKyYuhNc9RG5xEgCnY8 OAf9CqmljpCSUHptMkCyS6QZ5Ym2YcHgTD9Y1AgzXCzZHY/cY8AkfjN56BrQ/yn/v/8m 7b8h7hwpYZ1zqGvocxA44p4vmBaaPOPWUaz3I475Ip22iKunrtEK5b12h7PN/2bcrk5f hx5M1bedGY+lrzv0Fd5NfBDdOGSjtYF6nsUrAuGebjQXVQxNCpvO9KOTVnqJM91whrCc 8d+2ZcJJUuUf0ajLFAxcq6p+zJ5/ko74mmt9pJRQb6PJQoDHF3Eld/9bUGmOaHWeM8Bb gvVg== X-Forwarded-Encrypted: i=1; AJvYcCUV41HdgpTWEE9k6s3znBBr6jeotQnvt+t5eiWNQqO6b6pSPKkuzJDai6/zJVEu+XFKghus3mGpOXjdAwg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6WvfobnkWUgvZHTnRat4eGWBNX9DvQOQjL5AL0J5ifBm64wl4 qLk0aFZIckT8KOVL9RQhYNYKQ0Myq2FzTas4F9CIh3E5YKZRW/YWZrNPhkfT6ZjxtrY= X-Gm-Gg: ATEYQzyatUsPejqVjvJ+3NnsztVBo6O9TSgB5ee+KQfwFWDtlP8cUKBDM+dKnP7SWKa UL8G4n5N+dwwC2bnhEDHkKpKmH9KWrOiYDG96bALzoF9tMwqhwdwqMHuPZJIUZxhIHZt6AY2mKf 7mNRzv//pz08FaOIHklzw8nAec7tTJ7Z9KSCwbC1NCjFbZOvExFb1+LhlH22xlvsxjkKlrb9QwS LmdWFt8NN3+AxV3jpqwkKAUv/3LsJ7Qt3mxkN/sser9uqcSnvgg9hA6all3AkhaIaWlRkTESSdn Pr9y7oiGJ1L6XBc6XroEdWWB+Csl2k0Ygvr92dJtYbNhD6cKWWss9NLCiAY8dqmwyAXexOfiVjH vWwMuvYgRu4VaY0OcXirb5UAuoIVi3JmFzj9ZSMH7yZDcRsCmyAb1UPNOe2aCl5FuvetDs1wlBS CrQwutx3cWs+y7IfLjyuzHyngIz7OY2DRj8X2xWSHHUmLNCDLgstUNtDBL2AZiwWplnPEUuqbj2 yqYoVr6wF+xJ4i4xMw= X-Received: by 2002:ac8:574b:0:b0:506:534b:7871 with SMTP id d75a77b69052e-508f496e9b7mr109431651cf.46.1772993962390; Sun, 08 Mar 2026 11:19:22 -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-508f653c566sm48622921cf.8.2026.03.08.11.19.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 11:19:21 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vzIim-0000000AbBt-0YB7; Sun, 08 Mar 2026 15:19:20 -0300 Date: Sun, 8 Mar 2026 15:19:20 -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: <20260308181920.GH1687929@ziepe.ca> References: <20260307-dma-debug-overlap-v1-0-c034c38872af@nvidia.com> <20260307-dma-debug-overlap-v1-2-c034c38872af@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: <20260307-dma-debug-overlap-v1-2-c034c38872af@nvidia.com> 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. 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. It should only be used by callers like RDMA/DRM/etc where they have historical uAPI that has never supported incoherent DMA operation and are an exception to the normal DMA API requirements. The problem is to limit the use of that flag to only a few approved places. I fear adding such a flag wide open would open the door to widespread driver abuse. These days we have 'export symbol for module' so maybe there is a way to do it with safety? I'd really like this right now because CC systems are forcing SWIOTLB and things like RDMA userspace are unfixably broken with SWIOTLB. The uAPI it has simply cannot work with it. I'd much rather to immediate fail than suffer data corruption. Jiri was looking at adding some hacky "is cc" check, but I'd far prefer a proper flag that covered all the uAPI breaking cases. Jason