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 E3EE4ECAAD3 for ; Thu, 1 Sep 2022 19:17:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81D5880044; Thu, 1 Sep 2022 15:17:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CBF68000D; Thu, 1 Sep 2022 15:17:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6952480044; Thu, 1 Sep 2022 15:17:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5B7C68000D for ; Thu, 1 Sep 2022 15:17:09 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 28719A1173 for ; Thu, 1 Sep 2022 19:17:09 +0000 (UTC) X-FDA: 79864474578.06.53E79CE Received: from ale.deltatee.com (ale.deltatee.com [204.191.154.188]) by imf01.hostedemail.com (Postfix) with ESMTP id 40BB04004B for ; Thu, 1 Sep 2022 19:17:07 +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=mn3VERy0s8rwu2J3nmnzKseb1Xv+6b55gPqcv2R29Do=; b=YzaqHznkMBYAnCSOLqSHdegCox YKGC4eoem9/8GT5zgWrOSDaNjktJxP8yRvpJYQxa1Z8TVgSJMiKxRYBzMwVpxfst2k9K0nTOV1HBS g+ph5690L3SgBn1e1YgO7JjiEYivUW+H3wpACNHc9roxwPBpKqP9k77Y82r0mkv/FNfPaaPUHfTvB p4qZfGw6uCBlrSY263wg1z6zYHA/Re3+5UA8DJ6RvGYmERMmO74bYgDyuhsaCDe3OouNe43APnOcv 6drCz4JVkp2sBvXA1RP/eGJ/WdeAGxetZaWgUxT+1aOmV3OaCU44xJq4EEu+L4J8FIFcXmhtYUgpU 1D7gy7Vw==; 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 1oTpgS-00Dx2S-Se; Thu, 01 Sep 2022 13:17:01 -0600 Message-ID: Date: Thu, 1 Sep 2022 13:16:54 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-CA To: Greg Kroah-Hartman 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 , =?UTF-8?Q?Christian_K=c3=b6nig?= , 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 References: <20220825152425.6296-1-logang@deltatee.com> <20220825152425.6296-8-logang@deltatee.com> <4a4bca1e-bebf-768f-92d4-92eb8ae714e1@deltatee.com> From: Logan Gunthorpe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 24.64.144.200 X-SA-Exim-Rcpt-To: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, hch@lst.de, dan.j.williams@intel.com, jgg@ziepe.ca, christian.koenig@amd.com, jhubbard@nvidia.com, ddutile@redhat.com, willy@infradead.org, daniel.vetter@ffwll.ch, 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, sbates@raithlin.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH v9 7/8] PCI/P2PDMA: Allow userspace VMA allocations through sysfs 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) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662059828; 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=mn3VERy0s8rwu2J3nmnzKseb1Xv+6b55gPqcv2R29Do=; b=MAtecnodMXMSLkstpN5nDJdQEgOQ3A7mdTqtkbBdfhMRYJ8ZEuMPEKcoYQsc+M09E7FeVw 6coLF4MQZmX5wZEv5skn0BKQahAqqiNuuFTDo4g0kUUNAwNkUuiqNpXsYAwEbg0I8ZMXus vxNmUfWBXGRGV6/xs9/933IrlNThEi4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=deltatee.com header.s=20200525 header.b=YzaqHznk; spf=pass (imf01.hostedemail.com: domain of logang@deltatee.com designates 204.191.154.188 as permitted sender) smtp.mailfrom=logang@deltatee.com; dmarc=pass (policy=none) header.from=deltatee.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662059828; a=rsa-sha256; cv=none; b=WA4SsQrmCql1YQV0CHIvrJMuf15Yds/RaboZrOj41LIp3wxijWVa/Z4fn3sNnphUE/yxNf uILENDHrFhEBNNI5kd+suJg8J9C09lVo17wDw8bm3cnkWG/dUw9KdvlJl1arH0XIQ6ksbK m0WNlEl0rYUKcBl8hK8H3oIkBCgSzTU= X-Stat-Signature: auqxbkktwpjgnxw9qehwk9qru6bsui8m X-Rspamd-Queue-Id: 40BB04004B Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=deltatee.com header.s=20200525 header.b=YzaqHznk; spf=pass (imf01.hostedemail.com: domain of logang@deltatee.com designates 204.191.154.188 as permitted sender) smtp.mailfrom=logang@deltatee.com; dmarc=pass (policy=none) header.from=deltatee.com X-Rspamd-Server: rspam12 X-Rspam-User: X-HE-Tag: 1662059827-207968 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 2022-09-01 12:36, Greg Kroah-Hartman wrote: > On Thu, Sep 01, 2022 at 12:14:25PM -0600, Logan Gunthorpe wrote: >> 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. This surprises me. Can you elaborate on this classic issue? I've definitely seen uses of devm that expect the calls will be torn down in reverse order they are added. The existing p2pdma code will certainly fail quite significantly if a devm_kzalloc() releases its memory before the devm_memmap_pages() cleans up. There's also already an action that is used to cleanup before the last devm_kzalloc() call happens. If ordering is not guaranteed, then devm seems fairly broken and unusable and I'd have to drop all uses from this code and go back to the error prone method. Also what's the point of devm_add_action_or_reset() if it doesn't guarantee the ordering or the release? But if it's that important I can make the change to these patches for v10. Logan