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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 62AB7C43334 for ; Thu, 2 Jun 2022 16:16:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id EE064828A5; Thu, 2 Jun 2022 16:16:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUxVVTA1_dbe; Thu, 2 Jun 2022 16:16:32 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id D573E828A9; Thu, 2 Jun 2022 16:16:31 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B8B22C0039; Thu, 2 Jun 2022 16:16:31 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1BC25C002D for ; Thu, 2 Jun 2022 16:16:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0ABA7828A9 for ; Thu, 2 Jun 2022 16:16:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epm2yVPKV4-J for ; Thu, 2 Jun 2022 16:16:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from ale.deltatee.com (ale.deltatee.com [204.191.154.188]) by smtp1.osuosl.org (Postfix) with ESMTPS id C1A5C828A5 for ; Thu, 2 Jun 2022 16:16:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=deltatee.com; s=20200525; h=Subject:In-Reply-To:From:References:Cc:To: MIME-Version:Date:Message-ID:content-disposition; bh=W4T5PIIcGVVrvnJ3j+rtildRWdfS99SqV9DDMh3z6VA=; b=mFcvfvBdKsB2BJNNUrV2R2TggK 1Px0GYS7XkvGiTWTnZL/2iur+Kwoi7+M1jX7ntdXKfQJgxbmlrV2IKqir+oid4k4eEGTQLkoy4Ej6 5ZG9+5TOIBSiRlulo/Z8oASkCGdc8NEe+OT+P7LSZ2mv/eVC6P+tVixruEzq8ynubixg6CxcQoxPy F8HWcOevW1q3ZFYm1r8abYAOFD8Od08vH+hmLVbSXTbE3X0tUfar47n3TwHAH5FaK7Pdl9jU28pUr /4DQK3TDmrdpP1fNME8UkG4a7Pk0pi6CcP00XrNuudfB9AScd2GS+ujbPOIupoHRYNc++RS2G7b5x +U5oZZ4A==; Received: from s0106a84e3fe8c3f3.cg.shawcable.net ([24.64.144.200] helo=[192.168.0.10]) by ale.deltatee.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nwnUh-00ENsn-U9; Thu, 02 Jun 2022 10:16:20 -0600 Message-ID: <400baba7-1cd6-09d4-4de9-2a73f08afc79@deltatee.com> Date: Thu, 2 Jun 2022 10:16:10 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-CA To: Jason Gunthorpe References: <20220407154717.7695-1-logang@deltatee.com> <20220407154717.7695-21-logang@deltatee.com> <20220527125501.GD2960187@ziepe.ca> <20220527190307.GG2960187@ziepe.ca> <20220602000038.GK2960187@ziepe.ca> From: Logan Gunthorpe In-Reply-To: <20220602000038.GK2960187@ziepe.ca> X-SA-Exim-Connect-IP: 24.64.144.200 X-SA-Exim-Rcpt-To: jgg@ziepe.ca, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, sbates@raithlin.com, hch@lst.de, dan.j.williams@intel.com, christian.koenig@amd.com, jhubbard@nvidia.com, ddutile@redhat.com, willy@infradead.org, daniel.vetter@ffwll.ch, andrzej.jakowski@intel.com, dave.b.minturn@intel.com, jason@jlekstrand.net, dave.hansen@linux.intel.com, jianxin.xiong@intel.com, helgaas@kernel.org, ira.weiny@intel.com, robin.murphy@arm.com, martin.oliveira@eideticom.com, ckulkarnilinux@gmail.com, rcampbell@nvidia.com, bhelgaas@google.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH v6 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem() X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Cc: linux-pci@vger.kernel.org, Dave Hansen , linux-nvme@lists.infradead.org, Stephen Bates , linux-mm@kvack.org, Jason Ekstrand , Ira Weiny , Christoph Hellwig , Minturn Dave B , Martin Oliveira , Matthew Wilcox , Chaitanya Kulkarni , Bjorn Helgaas , Daniel Vetter , Ralph Campbell , John Hubbard , linux-block@vger.kernel.org, Bjorn Helgaas , Dan Williams , Jakowski Andrzej , Xiong Jianxin , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , =?UTF-8?Q?Christian_K=c3=b6nig?= X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2022-06-01 18:00, Jason Gunthorpe wrote: > On Fri, May 27, 2022 at 04:41:08PM -0600, Logan Gunthorpe wrote: >>> >>> IIRC this is the last part: >>> >>> https://lore.kernel.org/linux-mm/20220524190632.3304-1-alex.sierra@amd.com/ >>> >>> And the earlier bit with Christoph's pieces looks like it might get >>> merged to v5.19.. >>> >>> The general idea is once pte_devmap is not set then all the >>> refcounting works the way it should. This is what all new ZONE_DEVICE >>> users should do.. >> >> Ok, I don't actually follow how those patches relate to this. >> >> Based on your description I guess I don't need to set PFN_DEV and > > Yes > >> perhaps not use vmf_insert_mixed()? And then just use vm_normal_page()? > > I'm not sure ATM the best function to use, but yes, a function that > doesn't set PFN_DEV is needed here. > >> But the refcounting of the pages seemed like it was already sane to me, >> unless you mean that the code no longer has to synchronize_rcu() before >> returning the pages... > > Right. It also doesn't need to call unmap range or keep track of the > inode, or do any of that stuff unless it really needs mmap revokation > semantics (which I doubt this use case does) > > unmap range was only necessary because the refcounting is wrong - > since the pte's don't hold a ref on the page in PFN_DEV mode it is > necessary to wipe all the PTE explicitly before going ahead to > decrement the refcount on this path. > > Just stuff the pages into the mmap, and your driver unprobe will > automatically block until all the mmaps are closed - no different than > having an open file descriptor or something. Oh is that what we want? With the current method the mmaps are unmapped on unbind so that it doesn't block indefinitely. It seems more typical for resources to be dropped quickly on unbind and processes that are using them will get an error on next use. Logan _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu