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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 847CFCCA47B for ; Tue, 5 Jul 2022 07:51:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231124AbiGEHvQ (ORCPT ); Tue, 5 Jul 2022 03:51:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230510AbiGEHvP (ORCPT ); Tue, 5 Jul 2022 03:51:15 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E0C5DF4B; Tue, 5 Jul 2022 00:51:14 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 7CBB668AA6; Tue, 5 Jul 2022 09:51:08 +0200 (CEST) Date: Tue, 5 Jul 2022 09:51:08 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Logan Gunthorpe , Christoph Hellwig , 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, Stephen Bates , Dan Williams , Christian =?iso-8859-1?Q?K=F6nig?= , John Hubbard , Don Dutile , Matthew Wilcox , Daniel Vetter , Minturn Dave B , Jason Ekstrand , Dave Hansen , Xiong Jianxin , Bjorn Helgaas , Ira Weiny , Robin Murphy , Martin Oliveira , Chaitanya Kulkarni , Ralph Campbell , Bjorn Helgaas Subject: Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem() Message-ID: <20220705075108.GB17451@lst.de> References: <20220615161233.17527-1-logang@deltatee.com> <20220615161233.17527-21-logang@deltatee.com> <20220629064854.GD17576@lst.de> <99242789-66a6-bbd2-b56a-e47891f4522e@deltatee.com> <20220629175906.GU23621@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220629175906.GU23621@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, Jun 29, 2022 at 02:59:06PM -0300, Jason Gunthorpe wrote: > I've tried in the past, this is not a good idea. There is no way to > handle failures when a VMA is dup'd and if you rely on private_data > you almost certainly have to alloc here. > > Then there is the issue of making the locking work on invalidation > which is crazy ugly. > > > I was not a fan of the extra code for this either, but I was given to > > understand that it was the standard way to collect and cleanup VMAs. > > Christoph you tried tried to clean it once globally, what happened to > that? Al pointed out that there are various places that rely on having a separate file system. I might be able to go back to it and see if we could at least do it for some users. But what also really matters here: I don't want every user that wants to be able to mmap a character device to do all this work. The layering is simply wrong, it needs some character device based helpers, not be open code everywhere. In fact I'm not even sure this should be a character device, it seems to fit it way better with the PCI sysfs hierchacy, just like how we map MMIO resources, which these are anyway. And once it is on sysfs we do have a uniqueue inode and need none of the pseudofs stuff, and don't need all the glue code in nvme either. 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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.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 49B21C433EF for ; Tue, 5 Jul 2022 07:51:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C53EC40502; Tue, 5 Jul 2022 07:51:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C53EC40502 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH-LabpYks0b; Tue, 5 Jul 2022 07:51:20 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 9E64340327; Tue, 5 Jul 2022 07:51:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9E64340327 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4D308C0032; Tue, 5 Jul 2022 07:51:19 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 584BFC002D for ; Tue, 5 Jul 2022 07:51:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3359281B98 for ; Tue, 5 Jul 2022 07:51:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3359281B98 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 I58hcNl8IF00 for ; Tue, 5 Jul 2022 07:51:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0AFFA81916 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0AFFA81916 for ; Tue, 5 Jul 2022 07:51:15 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 7CBB668AA6; Tue, 5 Jul 2022 09:51:08 +0200 (CEST) Date: Tue, 5 Jul 2022 09:51:08 +0200 From: Christoph Hellwig To: Jason Gunthorpe Subject: Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem() Message-ID: <20220705075108.GB17451@lst.de> References: <20220615161233.17527-1-logang@deltatee.com> <20220615161233.17527-21-logang@deltatee.com> <20220629064854.GD17576@lst.de> <99242789-66a6-bbd2-b56a-e47891f4522e@deltatee.com> <20220629175906.GU23621@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220629175906.GU23621@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) 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 , Xiong Jianxin , Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Logan Gunthorpe , Christian =?iso-8859-1?Q?K=F6nig?= 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 Wed, Jun 29, 2022 at 02:59:06PM -0300, Jason Gunthorpe wrote: > I've tried in the past, this is not a good idea. There is no way to > handle failures when a VMA is dup'd and if you rely on private_data > you almost certainly have to alloc here. > > Then there is the issue of making the locking work on invalidation > which is crazy ugly. > > > I was not a fan of the extra code for this either, but I was given to > > understand that it was the standard way to collect and cleanup VMAs. > > Christoph you tried tried to clean it once globally, what happened to > that? Al pointed out that there are various places that rely on having a separate file system. I might be able to go back to it and see if we could at least do it for some users. But what also really matters here: I don't want every user that wants to be able to mmap a character device to do all this work. The layering is simply wrong, it needs some character device based helpers, not be open code everywhere. In fact I'm not even sure this should be a character device, it seems to fit it way better with the PCI sysfs hierchacy, just like how we map MMIO resources, which these are anyway. And once it is on sysfs we do have a uniqueue inode and need none of the pseudofs stuff, and don't need all the glue code in nvme either. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu