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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22B5CC433F5 for ; Fri, 8 Oct 2021 07:25:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3EDA0608FE for ; Fri, 8 Oct 2021 07:25:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3EDA0608FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rasmusvillemoes.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 882F5900002; Fri, 8 Oct 2021 03:25:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80D486B0072; Fri, 8 Oct 2021 03:25:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68516900002; Fri, 8 Oct 2021 03:25:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 522D86B0071 for ; Fri, 8 Oct 2021 03:25:16 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DBFCE1827059C for ; Fri, 8 Oct 2021 07:25:15 +0000 (UTC) X-FDA: 78672434190.34.1623680 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf04.hostedemail.com (Postfix) with ESMTP id 836F4500033E for ; Fri, 8 Oct 2021 07:25:15 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id b20so35922829lfv.3 for ; Fri, 08 Oct 2021 00:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EaBStkQbJ/56vDWRGxe1cWvLB2apSJpVfbn9rFFy6VQ=; b=PJCmaxvVuKBNAN4Njn5KUcl6g383j4Vb5tnx0nJDv7g7SIS1wkwDlY3kI9KLUtYBGH El6Xpm2x6d5DGTbE+erN2bbm2OaVIeIMjX/QNQC9hjV0HRf8ITLHg98hNuiinUeNzZN4 mmP61pgb8No6pnjZtSHAjQdlM19ljPWW9RzTo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EaBStkQbJ/56vDWRGxe1cWvLB2apSJpVfbn9rFFy6VQ=; b=MmlgL2KJ5T7YGy78s7zQSHqN+Ui3mW0P0kM7JC9stxy9A6JiaNU6TXRpPEUa1x+7jd fXPhSq3wt6bkeqryDn+WbRyx/OOq0EnkryZfKGa4fI12M50WnZrcN1h0HQHQZxJcK3Q7 I3Sm7nbhZvuqpgH66IzS411Gg2o1Y9X3lCFM3XVwUG2Y+Vzq9JyHf0ksiRzWSPnXaAOr AoIBB1h6O1NNR7q/yesrSEjNWHAC+PO6vdMT2Pyy9qiw/VE2R2tozkhZXVBisnDTKdYD qvaCGvr6AXbPGaGSObEqu1Mf2xK0sC+l9z2FGxx38pCOiXwqnNP8C8OsIjufzyA4G8Nr uVVg== X-Gm-Message-State: AOAM5325LAKKQrLzyo8c/BSdzFxchUS3idl7cmOPr3TKKENhgFDVVTrX I8JJ+amk5yGfThorHn/5H46udQ== X-Google-Smtp-Source: ABdhPJyws/BVjzbw9wNLNS1RMYaM2JlFjun6Yxax+9odWgUt7MAIeetzTEZOk8KQrENUxaeIcUJSfw== X-Received: by 2002:a05:6512:ace:: with SMTP id n14mr8818303lfu.460.1633677913738; Fri, 08 Oct 2021 00:25:13 -0700 (PDT) Received: from [172.16.11.1] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id i12sm168955lfb.234.2021.10.08.00.25.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 00:25:12 -0700 (PDT) Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: John Hubbard , Suren Baghdasaryan , Kees Cook Cc: Michal Hocko , Pavel Machek , David Hildenbrand , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , Jonathan Corbet , Al Viro , Randy Dunlap , Kalesh Singh , Peter Xu , rppt@kernel.org, Peter Zijlstra , Catalin Marinas , vincenzo.frascino@arm.com, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, Yu Zhao , Will Deacon , fenghua.yu@intel.com, thunder.leizhen@huawei.com, Hugh Dickins , feng.tang@intel.com, Jason Gunthorpe , Roman Gushchin , Thomas Gleixner , krisman@collabora.com, Chris Hyser , Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , Cyrill Gorcunov , Muchun Song , Viresh Kumar , Thomas Cedeno , sashal@kernel.org, cxfcosmos@gmail.com, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team References: <20211006175821.GA1941@duo.ucw.cz> <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> <202110071111.DF87B4EE3@keescook> From: Rasmus Villemoes Message-ID: Date: Fri, 8 Oct 2021 09:25:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=PJCmaxvV; spf=pass (imf04.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.167.54 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 836F4500033E X-Stat-Signature: c99c6pbpn3sb9tktd1wotk7t58mwp6bu X-HE-Tag: 1633677915-982065 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 07/10/2021 21.02, John Hubbard wrote: > On 10/7/21 11:50, Suren Baghdasaryan wrote: > ... >>>> The desire is for one of these two parties to be a human who can get >>>> the data and use it as is without additional conversions. >>>> /proc/$pid/maps could report FD numbers instead of pathnames, which >>>> could be converted to pathnames in userspace. However we do not do >>>> that because pathnames are more convenient for humans to identify a >>>> specific resource. Same logic applies here IMHO. >>> >>> Yes, please. It really seems like the folks that are interested in this >>> feature want strings. (I certainly do.) For those not interested in the >>> feature, it sounds like a CONFIG to keep it away would be sufficient. >>> Can we just move forward with that? >> >> Would love to if others are ok with this. >> > > If this doesn't get accepted, then another way forward would to continue > the ideas above to their logical conclusion, and create a new file system: > vma-fs. Or: Why can't the library/application that wants a VMA backed by memory to have some associated name not just fd = open("/run/named-vmas/foobar#24", O_CLOEXEC|O_RDWR|O_EXCL|O_CREAT); unlink("/run/named-vmas/foobar#24"); ftruncate(fd, ...); mmap(fd); where /run/named-vmas is a tmpfs (probably with some per-user/per-app subdirs). That requires no changes in the kernel at all. Yes, it lacks the automatic cleanup of using real anon mmap in case there's a crash between open and unlink, but in an environment like Android that should be solvable. Rasmus