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 4CB25C43334 for ; Tue, 5 Jul 2022 07:51:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D9306B0071; Tue, 5 Jul 2022 03:51:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 488DA6B0073; Tue, 5 Jul 2022 03:51:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 377B66B0074; Tue, 5 Jul 2022 03:51:15 -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 27A186B0071 for ; Tue, 5 Jul 2022 03:51:15 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E28122128E for ; Tue, 5 Jul 2022 07:51:14 +0000 (UTC) X-FDA: 79652275668.16.E2623C5 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf25.hostedemail.com (Postfix) with ESMTP id 09F80A0014 for ; Tue, 5 Jul 2022 07:51:13 +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 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) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657007474; 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: in-reply-to:in-reply-to:references:references; bh=J1B6KU4RqQ75A+QkPts2j5YhHfWA4F26bHFXjCNuj/8=; b=06C3PRF+WOWW2MXCIJ+WUP3HDR+HeiJ81J6PHcaA23jg00zEi4uUBnumWAT0XIylFntCrP yNMCHgELQZ/JmIunbgpsKI68Ar7ZonRMXHCDUNWA/6F22NESKICLjbdcvSQ7PhiN2IKDee Sd55GtqpK9uqt/+1rTQqFtbM0yargRc= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=none (imf25.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657007474; a=rsa-sha256; cv=none; b=1mhGtyLwi7LqYoWUFUqEQRmpFXh4fDcmv/RBK/dgKpXwFgFP6NJ7EfAFMBwkv9vbPe3flM J/YzLYlMExqB2sCb77Af2UWeoKrdvlL7AVu/sNbp1sPRDmtC2iPdDFRm2kXv7wH0oj1ybd 0sHeAYiO3n5Z1vIH5Mtc7wzgcaWPKIs= X-Stat-Signature: msn4qhupz8456fa73xuidcxmcwycxbrz X-Rspamd-Queue-Id: 09F80A0014 Authentication-Results: imf25.hostedemail.com; dkim=none; spf=none (imf25.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1657007473-284377 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: 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.