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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DA5FD13592 for ; Mon, 28 Oct 2024 02:01:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AC4E6B0095; Sun, 27 Oct 2024 22:01:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85BBC6B0096; Sun, 27 Oct 2024 22:01:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 723706B0098; Sun, 27 Oct 2024 22:01:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 53DDD6B0095 for ; Sun, 27 Oct 2024 22:01:14 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0EF054067F for ; Mon, 28 Oct 2024 02:01:02 +0000 (UTC) X-FDA: 82721357292.07.6C606DF Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by imf10.hostedemail.com (Postfix) with ESMTP id 050C8C0023 for ; Mon, 28 Oct 2024 02:01:00 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Jowa3iy+; spf=none (imf10.hostedemail.com: domain of baolu.lu@linux.intel.com has no SPF policy when checking 192.198.163.13) smtp.mailfrom=baolu.lu@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730080715; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2q8GANiJ1rQY2IO2E028oZkDcKvNDlvO5hi8LqfzTqM=; b=ksES/It2u4uA78Hr1m8uEveR1uBxfKg61SQfPMuSTNapcab+We0tWcwKuAN8V38AjCvaYL IYc0cvbCRUit+otguxvloywm6gvIhswIbPBFqjlt90P3ZWy1U0OJVZ0Q5uX294uJGxZuVp De69zpg1xW7MiFMmviLzZ/RsIFpmA5Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730080715; a=rsa-sha256; cv=none; b=KOu9JdTdPJo8lRVBJO5T1vPXWdfzZFwMIC/y5Pj/MkMNvYzCff1kvF6w5vJ2SIuYKVuK0K C9uaK19m7EwJJOcu1PVn9KOxO2MkRi85Bxko/VIDePVP2s7/ghHBeSXPZuvB1HeNCtZe+4 detGcQN8PWMaCrjb+8ImkZJENG+ff2E= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Jowa3iy+; spf=none (imf10.hostedemail.com: domain of baolu.lu@linux.intel.com has no SPF policy when checking 192.198.163.13) smtp.mailfrom=baolu.lu@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730080871; x=1761616871; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=O3Ovtbf3MrmDzHqqK2oXEfGTFDsY4Dl/uMRNNzQ0jlU=; b=Jowa3iy+rqa+MFxq5A3r3n0aOPVNMQTkbD6wEktvTPHc/OZmxYIsHTgs Yz39GpIv5MI9psYnUt1ChQghLmLpSvewKmRhUOxI6gxeSiaVH0hoY8ROV kP/I6zhjFFVBk2uUpNPzHitfX+OPPjoGRblbl36BYDHEA1rSTU5zzLEuG jOfMctHdvflJrDPTiZx+IG22hLhALh0xiLf9JB4ovp4nCWctfoXLf8CTN F66GaU9tzTbTmaunaFuGkEZD+N0f7CW2ZRStVI2Q7V0VxZe/+akf85iHm WDdkzFZjvwMwwkxBfzKFBNqaj+N8mA6BOAPnYhGN14QBMei8qQKEWZMvj g==; X-CSE-ConnectionGUID: 9spaF1XiTTWj4xL+76OXIw== X-CSE-MsgGUID: NMUk1vgxSsycWv50oNqxPQ== X-IronPort-AV: E=McAfee;i="6700,10204,11238"; a="32530612" X-IronPort-AV: E=Sophos;i="6.11,238,1725346800"; d="scan'208";a="32530612" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2024 19:01:09 -0700 X-CSE-ConnectionGUID: qpBwISFYS46tXapmQ++WeA== X-CSE-MsgGUID: cTaC7appS+WESSNDD4yrMw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,238,1725346800"; d="scan'208";a="104792722" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.238.0.51]) ([10.238.0.51]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2024 19:00:28 -0700 Message-ID: <6a9366a5-7c5b-449c-b259-8e2492aae2a1@linux.intel.com> Date: Mon, 28 Oct 2024 10:00:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, Leon Romanovsky , Keith Busch , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 07/18] dma-mapping: Implement link/unlink ranges API To: Leon Romanovsky , Jens Axboe , Jason Gunthorpe , Robin Murphy , Joerg Roedel , Will Deacon , Christoph Hellwig , Sagi Grimberg References: Content-Language: en-US From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 050C8C0023 X-Stat-Signature: 1yufrxd1gu799jfpas9y861usz5r7ydf X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1730080860-12340 X-HE-Meta: U2FsdGVkX1/nwmKoB4ZLjQuvG7zGrCHOgWtyHBnDEg50T6OqhLvdrDnhm8OclWmPqkfFjhlpGzhPssoJqugQ8VJ/tO8VAtzyfrdlh1z515dtdrfHPH3cmrv8P2Rk0g+xCshoxPkM2z5HGmKqiVNjG8XcH9u+rG3giiyZwRhMTaiah96PffXwta9mImguzIj43so2sn4CTPQuNELDOzH3FJ9CIgxXbpb2CjuZyvJp+7Qu3Lv3wknHhLHoO96CjSDP525GZWHkM4MtjuUJzsOtEuxqqkvvu7KV3WA6rOMBeZCqJnFlWxKq2oonb/sG27yTpFnCtOOmlocnqGKFUmlfg1ly6hX2yXzafXMokxFYzyth0470UjxlU6DJVzWeyp09paIFiJShLVtU0LB2lVYFUExzxyGxJ3M9oyzakSdPbAAjDwe2eYRK7ac41vtON+Dpv1ADqqefa4RrfNTNFBKbBAp4XUFGVBhe9l1NLcVz8HnhQ5UyMjtkr9N5oUduIVuLkbCxvQtA62cxH+a+pxjF/TtSeACCuOPHMWzubbEmu3R+3+q6dnpFhByPiHQx5H8Cdzgb34qXe+03UCbaIQ2GH0lf4teFpwdl+c4HjHTRUaxnvozEFO7ysx2a26Yr1i3LsO6lAvyBxyMG182OeNVzIND141Tu9T/P9oVRL+GpLMjdEytSue+MKCR4LCFILjIFMdY8ID1dyELusXsIsy7DPitWfQDIgVf2K8U965GYRGAfHd1DA7/hu8z8yYmUGPzg4Vwfr7lFkDiN4rWXKzPmHPOfbiI86D8oLtLMUu2r4dbRRexR5paUZVdW8ckCLYk6tpVNudATmCGlWlEZIr/6knuYArk/+OoOn0rAB6MO9SzGBS37zvDw9M+vGpR7D5l8t/WagAkNvi4GD80wVFcNew0WZYzRAVAGeunrZvYWK6sLY5LqZY6JCqghF2iSw3mBQXAOneKZhwhyYT9eJ3S +A/FkI+5 QTQNMgDys8+nSc3iwbYCToqQwv0p9HcHEPnusisiOdSxRrRnkdUDTrSbK4a/T4OdVVb/l3vsBIWxxNKzuKv6RDGOl4947AQ87AHh6M3DmQk/VPY8q6Yr3kvWnOxk1ldLmbTyMHX9qetyPtszNYHZTgBI/RcS1SOJExr/7GfoPEWvdzoHwVYsSCpX4+MWgyoKXg5q6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/10/27 22:21, Leon Romanovsky wrote: > +/** > + * dma_iova_sync - Sync IOTLB > + * @dev: DMA device > + * @state: IOVA state > + * @offset: offset into the IOVA state to sync > + * @size: size of the buffer > + * @ret: return value from the last IOVA operation > + * > + * Sync IOTLB for the given IOVA state. This function should be called on > + * the IOVA-contigous range created by one ore more dma_iova_link() calls > + * to sync the IOTLB. > + */ > +int dma_iova_sync(struct device *dev, struct dma_iova_state *state, > + size_t offset, size_t size, int ret) > +{ > + struct iommu_domain *domain = iommu_get_dma_domain(dev); > + struct iommu_dma_cookie *cookie = domain->iova_cookie; > + struct iova_domain *iovad = &cookie->iovad; > + dma_addr_t addr = state->addr + offset; > + size_t iova_start_pad = iova_offset(iovad, addr); > + > + addr -= iova_start_pad; > + size = iova_align(iovad, size + iova_start_pad); > + > + if (!ret) > + ret = iommu_sync_map(domain, addr, size); > + if (ret) > + iommu_unmap(domain, addr, size); It appears strange that mapping is not done in this helper, but unmapping is added in the failure path. Perhaps I overlooked anything? To my understanding, it should like below: return iommu_sync_map(domain, addr, size); In the drivers that make use of this interface should do something like below: ret = dma_iova_sync(...); if (ret) dma_iova_destroy(...) > + return ret; > +} > +EXPORT_SYMBOL_GPL(dma_iova_sync); Thanks, baolu