Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1071260rwe; Thu, 1 Sep 2022 12:02:21 -0700 (PDT) X-Google-Smtp-Source: AA6agR4P3LoATrwqapo3gOJEzXJcFabRm2NEx32R1ykyWaKjfi5LKkCZxemQcf3QJWRA5SztA5DE X-Received: by 2002:aa7:d385:0:b0:447:d5ec:d452 with SMTP id x5-20020aa7d385000000b00447d5ecd452mr26512589edq.231.1662058940831; Thu, 01 Sep 2022 12:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662058940; cv=none; d=google.com; s=arc-20160816; b=CD2MiaLTwHmWHSonXyEFY3ycst1JBLuNVbIj/QzthBdrahwCvZTA0XlHmhGdk7PCo+ UkLmgkXjsHci2ku6eJubWflJVI1OTpbj7geNLxoWwAQqEfMBFq2ssHTu04mn3EAu+Hpt II61an3/EnPRJquRDZWZgnbBVo7wmKikNUosvKy0TzT8UsCOLuTmmzbcnNVuN0k1yZr8 BvSLG6h2ZkbrMTeAUzie+NohIEW+Fr71LzKDjdKWVJPzQspQtcVX1iZW5Wt/VHcgLqS0 iuoQyIDfCgxwazw7UL/dY840iOt7mnjweadd0VyeM6kFNwM/EayTaacWoorvp4fOhv+4 HPEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=1AT1S+3qhBfI4/31yANv2bvnScixdjnjUQEHEM7f9Bc=; b=teBzQV4wQoBZiQNsVu2VHpgdlvkBYRAsJbg7/A/w3PEewEgQQ9Pp0zUyLhf9C7iRb7 dEWF8LT9QzXS7+UYIr4voEL/8iztx3Fw1OhfdaDryUssytCoeyzZzjmPB5om37JNID/N Zb/DbdKOC2rrgnWpzG/EP4YeIHUrndHIRMRD3eij8ghMJ8ELCeUoJ51IEnJx3ExGLu2F 9J5u1n2q6mhAMCB5UIjfVHn1w+ZARMSe5hV6z4zuOsCHdhoHBJsSc09YaXER21D+Pn/5 ZFwg/AJ8oX1N1LU03Na1czC7Aw1iWHGdw713aMB1nOVEq0DaZ82TpArwjBfWiyRLgKj0 2TeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=xFeGxXLU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t2-20020a056402524200b00448375a5890si2662539edd.393.2022.09.01.12.01.55; Thu, 01 Sep 2022 12:02:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=xFeGxXLU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234791AbiIAShz (ORCPT + 99 others); Thu, 1 Sep 2022 14:37:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234684AbiIAShX (ORCPT ); Thu, 1 Sep 2022 14:37:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B29C4CA0E; Thu, 1 Sep 2022 11:36:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8A19F61CF7; Thu, 1 Sep 2022 18:36:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68479C433D6; Thu, 1 Sep 2022 18:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662057404; bh=4EGc98ePtGVoW/OVpl29pIB0Xv/vWLpMdUFKeCItABY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xFeGxXLUUQuSqZdVXhkzgw5JZFhnJkqiyA7MU8ELHe3FJve40mXqCLp9o6Fh+/lAf yijiTz3pzHkV1ZEn5hg/537CIQ4D8j2AVuE8Pd8EnOW7zd0tEDyU+ODP2GX+/Dt8iD Xilxi4k7yFbvYeFd6jE9lPw3HjO8pop87qrBfh24= Date: Thu, 1 Sep 2022 20:36:41 +0200 From: Greg Kroah-Hartman To: Logan Gunthorpe Cc: linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig , Dan Williams , Jason Gunthorpe , 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 , Stephen Bates Subject: Re: [PATCH v9 7/8] PCI/P2PDMA: Allow userspace VMA allocations through sysfs Message-ID: References: <20220825152425.6296-1-logang@deltatee.com> <20220825152425.6296-8-logang@deltatee.com> <4a4bca1e-bebf-768f-92d4-92eb8ae714e1@deltatee.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 01, 2022 at 12:14:25PM -0600, Logan Gunthorpe wrote: > > > > On 2022-09-01 10:42, Greg Kroah-Hartman wrote: > > On Thu, Sep 01, 2022 at 10:32:55AM -0600, Logan Gunthorpe wrote: > >> On 2022-09-01 10:20, Greg Kroah-Hartman wrote: > >>> On Thu, Aug 25, 2022 at 09:24:24AM -0600, Logan Gunthorpe wrote: > >>>> + /* > >>>> + * Removing the alloc attribute from sysfs will call > >>>> + * unmap_mapping_range() on the inode, teardown any existing userspace > >>>> + * mappings and prevent new ones from being created. > >>>> + */ > >>>> + sysfs_remove_file_from_group(&pdev->dev.kobj, &p2pmem_alloc_attr.attr, > >>>> + p2pmem_group.name); > >>> > >>> Wait, why are you manually removing the sysfs file here? It's part of > >>> the group, if you do this then it is gone for forever, right? Why > >>> manually do this the sysfs core should handle this for you if the device > >>> is removed. > >> > >> We have to make sure the mappings are all removed before the cleanup of > >> devm_memremap_pages() which will wait for all the pages to be freed. > > > > Then don't use devm_ functions. Why not just use the manual functions > > instead as you know when you want to tear this down. > > Well we haven't plugged in a remove call into p2pdma, that would be more > work and more interfaces touching the PCI code. Note: this code isn't a > driver but a set of PCI helpers available to other PCI drivers. > Everything that's setup is using the devm interfaces and gets torn down > with the same. So I don't really see the benefit of making the change > you propose. The issue is the classic one with the devm helpers. They do not lend themselves to resource management issues that require ordering or other sort of dependencies. Please do not use them here, just put in a remove callback as you eventually will need it anyway, as you have a strong requirement for what gets freed when, and the devm api does not provide for that well. thanks, greg k-h