From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 87252ECAAD3 for ; Wed, 7 Sep 2022 09:44:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BMq1iWhVlcP2ToyXVd/+pj5lcCidqOQv4N9/8cPB+hA=; b=3Kv8NR5ONaa6vb /UwtzzCmg1BvGfZtos8OG1DYoa3VNlig0yxrNCRwFQASkOK+H2QZ8vjLUTniRvtLwXlV7mhLTO1sZ 2AVjX8snaNPvGK1KFIIaFD7T8MiVUi+2BYVTz7tk4a3tsGWYBQEAvZB1hT4tz8kWJ0+foHLE/UyBr p+KEd67ru4WJF0vHbFjro1TS99OWzoVVmAJGR8p+bxLtNnMPboMwpagVcZL+DSjwAhlHkRiNF+cPT vmwDrgzKJpprLX03xvKE2B3Js9pwyxPaNySHUcRM6R8RoaNyD6S4FCK0AIA52hpvBYA/AhbPc+LhE 2UbI6PObvGULqbhlgtKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVraU-0050F1-G1; Wed, 07 Sep 2022 09:43:14 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVrLg-004sKL-Jc for linux-arm-kernel@lists.infradead.org; Wed, 07 Sep 2022 09:27:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 99D90139F; Wed, 7 Sep 2022 02:27:58 -0700 (PDT) Received: from [10.57.15.197] (unknown [10.57.15.197]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AE08F3F7B4; Wed, 7 Sep 2022 02:28:18 -0700 (PDT) Message-ID: <5d856574-4cd7-70d0-adcb-3e284fef315f@arm.com> Date: Wed, 7 Sep 2022 10:27:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent() Content-Language: en-GB To: Christoph Hellwig , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Rutland , Ard Biesheuvel References: <20220823122111.17439-1-will@kernel.org> <20220907090305.GA30704@lst.de> From: Robin Murphy In-Reply-To: <20220907090305.GA30704@lst.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220907_022756_769130_54FAA2A8 X-CRM114-Status: GOOD ( 21.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-09-07 10:03, Christoph Hellwig wrote: > On Tue, Aug 23, 2022 at 01:21:11PM +0100, Will Deacon wrote: >> arch_dma_prep_coherent() is called when preparing a non-cacheable region >> for a consistent DMA buffer allocation. Since the buffer pages may >> previously have been written via a cacheable mapping and consequently >> allocated as dirty cachelines, the purpose of this function is to remove >> these dirty lines from the cache, writing them back so that the >> non-coherent device is able to see them. > > Yes. > >> I'm slightly wary about this change as other architectures seem to do >> clean+invalidate here, but I'd like to hear what others think in any >> case. > > If arm64 is fine with having clean but present cachelines when creating > an uncached mapping for a cache line, the invalidate is not required. > > But isn't it better for the cache if these by definition useless > cachelines get evicted? > > My biggest concern here is that we're now moving from consolidating > these semantics in all the different architectures to different ones, > making a centralization of the policies even harder. FWIW I agree with Ard in not being entirely confident with this change. The impression I had (which may be wrong) was that the architecture never actually ruled out unexpected cache hits in the case of mismatched attributes, it just quietly stopped mentioning it at all. And even if the architecture did rule them out, how confident are we about errata that might still allow them to happen? It seems like we don't stand to gain much by removing the invalidation - since the overhead will still be in the clean - other than the potential for a slightly increased chance of rare and hard-to-debug memory corruption :/ Cheers, Robin. (who's spent the last few months elbow-deep in a hideous CPU cache erratum...) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel