Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1554153pxb; Thu, 7 Oct 2021 10:02:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxiva74TJtVt4KfzShIWVS1hTC1K11XO/wfYDM7WOv7rBk9bhOWAJsuxRWs+O6J/wd4Kuoc X-Received: by 2002:a17:907:1b06:: with SMTP id mp6mr6747216ejc.188.1633626159983; Thu, 07 Oct 2021 10:02:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633626159; cv=none; d=google.com; s=arc-20160816; b=iUSozh1zK4Ykt996O30cOHgIu/KdN0HunvikJaTikS1MHF11PxRJ3Ouup2acQ7EhwA YSNgB+UKoqri0TNEubbfWFgJFzgLD3p6cp/gzQ8EoIt35QWazmc+HzJKXfKh42FgZBIm XsJx04e4CpAUz0HYfbe9/YB4DidKzpPYzr8jSDVUP+KhiON95q//q2DJCaHCa+cH3xHd d9RD3di54M9G/8Amed5TFYpt4nwxabuLMNcKv69qbsoe72NUmQq6Fkmy2y2yJbMdiQOH ho7lvIR6Gx0Al5XwHt+N6h5H8HEf8KU2DbEH+PhHqa6eH+OICAKO8PHmSOwGDPHIcYaM /Fbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2roo7N2Af5V9MyzmKYbaAyLkAjMNad5Lcx6Zw/2fkDw=; b=q9xCNZmIbID7kJ8OFzrqpuoQyQm8NNRwmV00Pv2P3yhsiqhwSXfzs8EQMhethnh2xO V6cm0/nsEodyWRVlYKB+skjgJSur25OcG5zqiU0TYLKtyIpE7PJbWdwFzRZc1bUomSRt nHiP4FjRRlN4vYRxQvRLYeEaND2R3977dXXCXd0dgfJbwgl+tOsnFMiUmHhTkwVF72h2 FIfZE6mu7fYzwkAeWeW2e5h8KE3jpelK1RHoPMFo6tBsrnxWNUPNveHOYbFCNo1b7WVB +xUA7++A+T9J0ubsxc34R36v5XTpEnJoWDdBmoq2aCmqlPM+bkQpoIDVUKWPh20isTMq 0Yjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="BF0V/P/R"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f25si44729ejz.15.2021.10.07.10.02.15; Thu, 07 Oct 2021 10:02:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="BF0V/P/R"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243118AbhJGRA6 (ORCPT + 99 others); Thu, 7 Oct 2021 13:00:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243071AbhJGRAc (ORCPT ); Thu, 7 Oct 2021 13:00:32 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 464D2C0617AB for ; Thu, 7 Oct 2021 09:58:14 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id v195so14997431ybb.0 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=h77RBGmeU6fMSTCK6mgtE3At/PbeFWiX05Z3eabMHChskTPnWtCsMPptfSbAsaHZ2U 60yQ1aTs2Us8HLHmDpxTuVcVviJZM8/vKJ9ww0jbNXos3MX/JaMzE5kX84qsdj+sv1VD wcfuwfhyRQCGqFmfqq2zkUf2ENxQcxzcN88Dqsy760mlwKGvS2ycAMTe2aAdH9A8Vfm9 HYNgm+6UN6hFPgijNPBNO8Rhuh/VJJxWAE7o1zmi0JV+rV0MZh0pAxfhlnBVwikbiejE dyCkYpCG7ZrxD8eGzXS/hBF2PfxBLsNYEHoKoa+bfiet5qGdEo7FE0Oof5pfmBFcE8sM PHvg== X-Gm-Message-State: AOAM533YnncimjTks+Irkr3K9mYJh0mMUOaDqbtjvoRdBng6pkw2dF12 xrdqoiKEfBTeyS2dStKJr8vZ+FetSf2DoRk7L5hnvA== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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