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 D34D8C433F5 for ; Thu, 7 Oct 2021 16:58:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F6D561245 for ; Thu, 7 Oct 2021 16:58:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6F6D561245 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 F1566900002; Thu, 7 Oct 2021 12:58:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC4AD6B0071; Thu, 7 Oct 2021 12:58:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8C50900002; Thu, 7 Oct 2021 12:58:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id C71D76B006C for ; Thu, 7 Oct 2021 12:58:14 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 83F342D004 for ; Thu, 7 Oct 2021 16:58:14 +0000 (UTC) X-FDA: 78670249308.08.E8BF0B1 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf11.hostedemail.com (Postfix) with ESMTP id 36AE1F001D11 for ; Thu, 7 Oct 2021 16:58:14 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id s64so14809851yba.11 for ; Thu, 07 Oct 2021 09:58:14 -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=2roo7N2Af5V9MyzmKYbaAyLkAjMNad5Lcx6Zw/2fkDw=; b=BF0V/P/RYBknF8eb0/OEKCvyMrXtCN7yOB7aYUc4Q3DSSVccbU6hU/Vp3GE1apQlPk yCJ8FILh3vBMaV6UMR98Yk3R4LESqkJXOfzMJaNq0J0xcwQGKjybrHz82zAE8253QF5U UrA5n5kz5BEOAOfEt3IxCgvGcTkEactWfmwFQmOlC7i/x7fr1gPnCZ7mMOkUCHBS1wKq yGHPEL/dsN/yQHOPLxhwKxMAycOQ+wJsUwhCYd69xxjg/5jpc96uh6B5AzXr6x1nAaGb 4rMpmaLh9nnsuLiqWx8SDbHEao2TjWbvV54xGDaNALD9X/dQX8cczg3tkrOzgwrRUkVc BbSg== 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=2roo7N2Af5V9MyzmKYbaAyLkAjMNad5Lcx6Zw/2fkDw=; b=VKrewzdImL02jXQ4wGetnQ19Cm7PQMu2unNA+TeRbXs206QhDUTosrrRm031PIoiZi LrhKOHPnqmaw17tEkfzIAgsxPH9tNGQ5GXR5HHIBi9RC3s9SrxifTU6Bb3LPp6iL/Uc4 I7Di46t7YiqsxoBu1iN4plO/TIajmusGL4ilnCEeF/RpIG7x74oco5Pit19SxnoF3Kxt KB5MIGidku28MLE0Me1UGof+PkblUkR5dCjvu0PnBICJ0iihVbFbWLCpKML5uTd7/TrZ TpxIiu+RRue89Q6RNcvcHi4m8MHyzJ/lIPH2hnGjgaM7Jm7nnUYRqo01l8hjNSX2dpf5 nHRg== X-Gm-Message-State: AOAM531LY2VRX4+e9LlF3k9C592ZCM+XnIsvjx3Gg5uxHrSXytRfLFsm cAnvU5HbvpbNuLfDT8JowUQbJ1e7W0/z6kTN1Ggu0A== X-Google-Smtp-Source: ABdhPJym4VvtqHVKv+9+eKS28MNi7rcedM8+dLIhB+DoihLZf7xpYPXypfIrigb2ZhFzcnC3Vpr6i8o5c+Pf4K2R0w0= X-Received: by 2002:a25:d1d3:: with SMTP id i202mr6456843ybg.487.1633625893118; Thu, 07 Oct 2021 09:58:13 -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 09:58:02 -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-Server: rspam05 X-Rspamd-Queue-Id: 36AE1F001D11 X-Stat-Signature: 55akydmhmw73myq51osny3odmxynmh3u Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="BF0V/P/R"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1633625894-203118 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 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? Aside from the obvious inefficiency of requiring tools to parse maps/smaps and convert ids to names it also creates a tool->system dependency. Tools would have to know how the system interprets these IDs and on the systems where the ID is an inode they would have to know where the soflinks proposed by Rasmus reside and convert them. If I'm a tool developer who wants the tool to work on multiple systems this becomes quite messy. > > -- > Michal Hocko > SUSE Labs