From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 5167322DFA4 for ; Tue, 10 Mar 2026 23:34:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773185660; cv=none; b=dxOuaZLJyqi0cjIHY4gdvidCUY+RRT/2oWc/hYE0+p1HST2MXgrzfHYWucU97WGUsbOC9eGVJoUxD6pw5Sy1e2KMOu09TU+nTHSM9MGvr2AD28o0IgTWKomr5d6tpFvf/AT3FlAwfrkuBD30VGQ4YiKtEUK1NwCvpC7zIqaiFiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773185660; c=relaxed/simple; bh=zCDQLm/ti7Fh+tEKDvr17wEEpnNO9M6S1JIlwzo9Acs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T97+lkNHguXQfs0GoMmFzr9um9XB3VYawdYj7NFJeqbBboHsXctuTWu69ifaVIZloJRv8uISUtstSrZw3RSj2HG4dBaLVmfNFVbrM6WpUP9WiVAhMu5Ffy4MxNAFCt0NccylC6lF/Nx7ja7Nf35Quf2aeuyCT9qf/KWKy2PJdRM= 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=n6uuBTok; arc=none smtp.client-ip=209.85.222.169 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="n6uuBTok" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-8cd90401034so228792885a.0 for ; Tue, 10 Mar 2026 16:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1773185658; x=1773790458; 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=ZsiIyQd4tPWumA9ZQMQURKCway9cLZHNLfL2p5j0zPY=; b=n6uuBToksVmxqHTOnwcTLm8SqOdVqzC9hwvnG5NmSIkRODM387iQ8/SB+lOT8Ptfs7 AntGAIHr2j+KJKd7Ht01wP3JHYioR+yBvDmqCsxS0ZNUT/MfxjV/9iKVqU6jWGvn3FRd S7jFewWF6fcI2P1pRFuDDfkRKgVTzvVxjdp0HaNP0zGhB+xerwfmKufsEJ37kdXXGPaa L84tACDnV+c6YuNSiEucEikNCfCd1GAteMIYcxM7lzkcrrj1/3QbYYdvDNNIEfwaYc81 8qiLskG8qTIoCan1P8afsUeS7SOEGHdb8kkMe3+/G8joQgBS/Im9O8htDcO36Lu65AaN NtxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773185658; x=1773790458; 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=ZsiIyQd4tPWumA9ZQMQURKCway9cLZHNLfL2p5j0zPY=; b=A3lmiEmicQXJed3pp2ic5UMtIkjFzsica4wkq2NJz872lf3z0w4EHpmReldrFDuj40 qMIbxEu/+O8nMtLilk0lEAVoFY1nYJ1rJsktSOWc6xGi6atXZmgLjmlCOokrMsVS8xEL XpyW7nE0VFcApz0WdnZ1rG9VmWXGbmMRPkTuSfcLPK+Qw8jiX90Xoeenx+pB0rKW03rV 8WOfXOeuBPKB/nKKik6MgQe1juc88XYNgXJgsbIZomvbPe/F+TRbTWk8k6WeDLgREX5E sVRTqsfMr2Tpa/YANoI38r0YJAesCBqq5Mtv+MHmKby7m43gAyqpCqHsKVMCPlhBZSYh 2brA== X-Forwarded-Encrypted: i=1; AJvYcCW2SDjK9QhOBZvXb3ET+xbbCqBGWzheyLdijFjM8FPSGzDqpxdEYKo4V08C/mFAyt5k7sYFoM50RPMjnGc=@vger.kernel.org X-Gm-Message-State: AOJu0YxEAWozLyoMc6Atbsg7J/7g7IU8FFoqjvrDoe71BWkntkznFnxT Wyi8iE3jkywD8UJIaQFEe62wNi6Esiw/stERRTZVO0Zj4sPT+ao6OMj9OMIHTGpCzug= X-Gm-Gg: ATEYQzwl8Byuiy6sICExJ8XXnHRs2j7emXWFWmxdqcbClly1DFJKxljKUUnrDfXtbCf jpj3cJhNmsB8dBw/QsykJbdZFeSAZdeeIC4u4QQSGvfcLVQg6rnSEtJ6JR/FeUFf0z4u6nudzw2 E7PzWa8ppUvyYshiqA4m5qgxj1wQvz/qr54yJxKRn0Xcsow+9adLF1PBqHWGJ4+NrxqZ5319CJv uIHwUziX/w1I2HsL8uvARYqYNi/KjVEy1YdohDfoMJFXbE28rf5GrkgW1ehFv91P57wv4CKF4Wm Ve8J9afkTlswTddvmX/Y6rZogV2t5CIjcAEfcJL+s33PbZKAeOPmswbh9wtDJoT448uKlpNriWD ancgr1WqeNFgXA3V3e4dJeFNqA6LSILDzyJiZVKwvs6kM8Uiepgd8JJIPvGXVoZbIGC2A1fvfdc E6tVj2FdQs9Ecj09sbn8gtMmrw9tVy5vzwVqVsZuON+qoCOdSVJ2B3fAuP3H7ZUFdcYgOGwhrB0 SmeYp8/ X-Received: by 2002:a05:620a:3941:b0:8cd:982d:4101 with SMTP id af79cd13be357-8cda1a28be2mr93012785a.27.1773185658222; Tue, 10 Mar 2026 16:34:18 -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-8cda1fd6325sm24946085a.11.2026.03.10.16.34.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 16:34:17 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1w06ae-000000064gS-3fKz; Tue, 10 Mar 2026 20:34:16 -0300 Date: Tue, 10 Mar 2026 20:34:16 -0300 From: Jason Gunthorpe To: Marek Szyprowski Cc: Leon Romanovsky , 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: <20260310233416.GT1687929@ziepe.ca> References: <20260308184902.GR12611@unreal> <20260308230916.GI1687929@ziepe.ca> <20260309090342.GS12611@unreal> <20260309150502.GX12611@unreal> <20260309151356.GN1687929@ziepe.ca> <20260310123405.GR1687929@ziepe.ca> 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: On Tue, Mar 10, 2026 at 10:08:38PM +0100, Marek Szyprowski wrote: > On 10.03.2026 13:34, Jason Gunthorpe wrote: > > On Tue, Mar 10, 2026 at 10:45:38AM +0100, Marek Szyprowski wrote: > >> Jason is right. Indeed the rdma/uverbs case needs some extension to > >> ensure that the coherent mapping is used, what is not possible now. This > >> however doesn't mean that the DMA_ATTR_CPU_CACHE_OVERLAP is not needed > >> for that use case too. I'm open to accept both. The only question I have > >> is which name should we use? We already have DMA_ATTR_CPU_CACHE_CLEAN, > >> while DMA_ATTR_CPU_CACHE_OVERLAP and > >> DMA_ATTR_DEBUGGING_IGNORE_CACHELINES were proposed here. The last seems > >> to be most descriptive. > > If we do DMA_ATTR_REQUIRE_COHERENCE then I imagine it would internally > > also set DMA_ATTR_DEBUGGING_IGNORE_CACHELINES, but I'd prefer that > > detail not leak into the callers. > > Why DMA_ATTR_REQUIRE_COHERENCE should imply > DMA_ATTR_DEBUGGING_IGNORE_CACHELINES? AFAICT the purpose of the DMA API debugging cacheline tracking is to ensure that drivers are mapping things properly such that the cache flushing in incoherent systems can properly cache flush them without creating bugs (ie a dirty line overwriteing DMA'd data or something). If the mapping is REQUIRE_COHERENCE then it is prevented from running on systems where these cache artifacts can cause corruption, so we don't need to track them and we don't need the strict restrictions on what can be mapped. Which trips up and gives false positives for cases like RDMA, DRM, etc that are allowing userspace to multi-map userspace memory. Jason