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 E9873C433FE for ; Thu, 7 Oct 2021 17:50:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8493261248 for ; Thu, 7 Oct 2021 17:50:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8493261248 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A944E6B006C; Thu, 7 Oct 2021 13:50:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A45036B0071; Thu, 7 Oct 2021 13:50:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 932F6900002; Thu, 7 Oct 2021 13:50:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 8564F6B006C for ; Thu, 7 Oct 2021 13:50:37 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 43AEE31E69 for ; Thu, 7 Oct 2021 17:50:37 +0000 (UTC) X-FDA: 78670381314.38.3B0D67B Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf27.hostedemail.com (Postfix) with ESMTP id 013EB700194A for ; Thu, 7 Oct 2021 17:50:36 +0000 (UTC) Received: by mail-yb1-f171.google.com with SMTP id a7so15219737yba.6 for ; Thu, 07 Oct 2021 10:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NZcdFdLklF2D8wG5a28IWE28EnK8YrlZxMIkR94gcXg=; b=ii4rM8LzrLeipvkrLI6sF2XMP2pYN1zP2MMXV9cnIwjuzdbJHr0PQpeFOd3KTC+40n daj4ueJa2JF/8jd+7KE8ZpdESfFGK5l4m+2s8U8LxGYrHX3x2VnHVb6hcN50EYm5gTpM b15jPV6rJ1CCYg/qLLGgQltU7yUdmfasW7NkOnV9MZdefsJJgTwXpLQwCUZ0cvTxYu4b FM0XFSlN0hRSDl5ECN2ziCzhqY8CIM7jdFMI6hhJQTQQlt6bdbIr+oONLgaiJRJ2+bwz bV6byWHhxCzFT5G1xzBWvTFIQOn3OnOsIl8tjkX58LjAx81lAkDOzCb/AbEjkB4ITKcI LjIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NZcdFdLklF2D8wG5a28IWE28EnK8YrlZxMIkR94gcXg=; b=1FHw9S1O5TdM+3/bRr3OeythGglvn2PewWNhuG6kFkZUTQki1tO84IuRGewOAiDxHG G0fQAGj3pFEDUbEwBsDcF6F587oJ/u209qRu93BB8D9b9vapgsVc02bbRvQlviIpm5Bg TAEGTOZ53ILzSmdDb4JfIknxV1P4Zdd/3EyAv6kdA9IeJ7JXwTK93kU9NaNp7ILHJWx8 CW4p7scAwA6PaoRMxmN4trqSBIsRn8Wr/8KK4PWQWq1bmhKoekuzUN7byMfc8XHmhw7P BOQ4nz+T1b1rUVDkjUipTtD37E+dvCPF7mNb6AJqBH3xUv0fXLqLfqDVFOiXg5FuXRLX VmrQ== X-Gm-Message-State: AOAM531Ea4gfkrzXb0Q1PmTFfUWFYwTK2/Si6vaytyYQtVrv0L18b/WU OMiRTNh091xgFf4fYH08VOz4mJV7aMP1Ohk8/61u0g== X-Google-Smtp-Source: ABdhPJzonqs+AS4DlbvO/k8YV4nKIvqr0EcskkQ9+A+HIiE+vy9vaOXsKpto3iotn3+zxTci6VKhVWtr6PxcbeG6eUs= X-Received: by 2002:a25:8411:: with SMTP id u17mr6232017ybk.376.1633629035946; Thu, 07 Oct 2021 10:50:35 -0700 (PDT) MIME-Version: 1.0 References: <6b15c682-72eb-724d-bc43-36ae6b79b91a@redhat.com> <20211006175821.GA1941@duo.ucw.cz> <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 7 Oct 2021 10:50:24 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Michal Hocko Cc: Pavel Machek , Rasmus Villemoes , David Hildenbrand , John Hubbard , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Kees Cook , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 013EB700194A X-Stat-Signature: rh37sp4daa3jx6w85acbh5dsnkx5or4j Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ii4rM8Lz; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-HE-Tag: 1633629036-755662 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 Thu, Oct 7, 2021 at 10:31 AM Michal Hocko wrote: > > On Thu 07-10-21 09:58:02, Suren Baghdasaryan wrote: > > On Thu, Oct 7, 2021 at 9:40 AM Michal Hocko wrote: > > > > > > On Thu 07-10-21 09:04:09, Suren Baghdasaryan wrote: > > > > On Thu, Oct 7, 2021 at 3:15 AM Pavel Machek wrote: > > > > > > > > > > Hi! > > > > > > > > > > > >> Hmm, so the suggestion is to have some directory which contains files > > > > > > >> representing IDs, each containing the string name of the associated > > > > > > >> vma? Then let's say we are creating a new VMA and want to name it. We > > > > > > >> would have to scan that directory, check all files and see if any of > > > > > > >> them contain the name we want to reuse the same ID. > > > > > > > > > > > > > > I believe Pavel meant something as simple as > > > > > > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > > > > > > > $ touch $YOUR_FILE > > > > > > > $ stat -c %i $YOUR_FILE > > > > > > > > Ah, ok, now I understand the proposal. Thanks for the clarification! > > > > So, this would use filesystem as a directory for inode->name mappings. > > > > One rough edge for me is that the consumer would still need to parse > > > > /proc/$pid/maps and convert [anon:inode] into [anon:name] instead of > > > > just dumping the content for the user. Would it be acceptable if we > > > > require the ID provided by prctl() to always be a valid inode and > > > > show_map_vma() would do the inode-to-filename conversion when > > > > generating maps/smaps files? I know that inode->dentry is not > > > > one-to-one mapping but we can simply output the first dentry name. > > > > WDYT? > > > > > > No. You do not want to dictate any particular way of the mapping. The > > > above is just one way to do that without developing any actual mapping > > > yourself. You just use a filesystem for that. Kernel doesn't and > > > shouldn't understand the meaning of those numbers. It has no business in > > > that. > > > > > > In a way this would be pushing policy into the kernel. > > > > I can see your point. Any other ideas on how to prevent tools from > > doing this id-to-name conversion themselves? > > I really fail to understand why you really want to prevent them from that. > Really, the whole thing is just a cookie that kernel maintains for memory > mappings so that two parties can understand what the meaning of that > mapping is from a higher level. They both have to agree on the naming > but the kernel shouldn't dictate any specific convention because the > kernel _doesn't_ _care_. These things are not really anything actionable > for the kernel. It is just a metadata. 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. > > -- > Michal Hocko > SUSE Labs