Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp510156pxt; Thu, 12 Aug 2021 03:42:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEormfA9zDe4jS7TBwkrUJcRPbUX8oLe16JX2wQcOTMrdQU+MZHDzRw2u19KJlyJsM0qzA X-Received: by 2002:a05:6e02:12e7:: with SMTP id l7mr2509153iln.60.1628764958514; Thu, 12 Aug 2021 03:42:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628764958; cv=none; d=google.com; s=arc-20160816; b=f2MbGEgJfIjjdjS9DprHK4OAKPsypgSkENTF6GBzp+9ETmZ1Xz0sOVspHkWFPMLHAp qU/lw7sx+U0wXZvZXgb5Br5Gxn2flgQW5bXZVfg5pLYkb29qSZh8LuoKKq0p67A4CD8t ar8o5QSlCBVKFzWXG5btsFJ4sFcu9/qy0f2T8VfbVq0AmGSmP+xgGa88yx71BSIV8ItC 9vcR6CNmqOj3NepWK1mG33iRlYkNo3IhaHLvQwWFdHCHPQkyFSr9Us7jrBEJ9WHjRxIV Zvt+swJwEEhO1kSMjFLtWNhHEKoceuFQylGK4nHe0AW0JWNXDf7cBgpKy6LZuRkZd0ip c0OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=n4Vd5FrrqaHSei/ngzqk/9wYzAJFkuPyoHaRLlDQWaE=; b=ufmdO/Oy2BfekKGsYlD51vVoqUWhuM7962iROzoIdD4Tf1e2ZTpNaFsN5wtHen7bTM jGeqgy6VO5is+zCSkzP4RbWhKaDInoGuICQrTBsPQihgcVAD1n3UJ4MiwmptlH+LJMjq r4C1nRQ1OBzBPW/ifTrstNuJ9ndjwVnIicKFxU1sPHy15MDsnqw5+IjrdVQLJoPW+xRL qcGxkpR7fRO+4F6W68Vrg2nbudzbNxBZzLWsEaDK8sNQz1v6fw2h4EI5Lk8itWds3xsT XKla204yXxSHNObYdbDp8NeGl9DhLdJ6pI7U9O1DnscX5oVXhMKNGP2BbLK6KM5JNZpo qJYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w4si2289580ioa.95.2021.08.12.03.42.27; Thu, 12 Aug 2021 03:42:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235291AbhHLKih (ORCPT + 99 others); Thu, 12 Aug 2021 06:38:37 -0400 Received: from foss.arm.com ([217.140.110.172]:41732 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235428AbhHLKig (ORCPT ); Thu, 12 Aug 2021 06:38:36 -0400 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 9E3761042; Thu, 12 Aug 2021 03:38:09 -0700 (PDT) Received: from [10.57.36.146] (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 828633F718; Thu, 12 Aug 2021 03:38:08 -0700 (PDT) Subject: Re: [PATCH v3 2/5] dma-iommu: fix arch_sync_dma for map To: David Stevens Cc: Will Deacon , Joerg Roedel , Lu Baolu , Tom Murphy , iommu@lists.linux-foundation.org, open list References: <20210811024247.1144246-1-stevensd@google.com> <20210811024247.1144246-3-stevensd@google.com> <5b4fd891-a86a-42cd-5b69-bc08d351dd3a@arm.com> From: Robin Murphy Message-ID: Date: Thu, 12 Aug 2021 11:38:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-08-12 10:21, David Stevens wrote: > On Thu, Aug 12, 2021 at 3:47 AM Robin Murphy wrote: >> >> On 2021-08-11 03:42, David Stevens wrote: >>> From: David Stevens >>> >>> When calling arch_sync_dma, we need to pass it the memory that's >>> actually being used for dma. When using swiotlb bounce buffers, this is >>> the bounce buffer. Move arch_sync_dma into the __iommu_dma_map_swiotlb >>> helper, so it can use the bounce buffer address if necessary. This also >>> means it is no longer necessary to call iommu_dma_sync_sg_for_device in >>> iommu_dma_map_sg for untrusted devices. >>> >>> Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers") >>> Signed-off-by: David Stevens >>> --- >>> drivers/iommu/dma-iommu.c | 16 +++++++--------- >>> 1 file changed, 7 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c >>> index 54e103b989d9..4f0cc4a0a61f 100644 >>> --- a/drivers/iommu/dma-iommu.c >>> +++ b/drivers/iommu/dma-iommu.c >>> @@ -576,6 +576,9 @@ static dma_addr_t __iommu_dma_map_swiotlb(struct device *dev, phys_addr_t phys, >>> memset(padding_start, 0, padding_size); >>> } >>> >>> + if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) >> >> Make that an "else if" - otherwise you're just reintroducing the same >> thing that the third hunk is trying to clean up. > > swiotlb_tbl_map_single only copies into the swiotlb buffer, it doesn't > do any architectural syncing. So this block is necessary in the > swiotlb case as well, for iommu_dma_map_page to work properly. Urgh, apologies again - I had a mental short-circuit and was convinced that the SWIOTLB call already did its own cache maintenance. I really should have learned by now not to review fiddly patches like these while tired... > The third chunk is a separate optimization, so I'll split it out into > its own patch. It's still a logical part of this change - cleaning up the potentially wrong sync while you make sure the right one happens. Even more so if you make the fix the better way by having iommu_dma_map_sg_swiotlb() call iommu_dma_map_page(). Robin.