Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1680376pxb; Thu, 7 Oct 2021 12:44:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPmQ/C1WUWw16r9PvKzaW/6/PJCA9G8u/g8ExzJwwcwy5bMBsp6S9065bGD0vSnXTnKQnb X-Received: by 2002:a17:90a:b384:: with SMTP id e4mr6900503pjr.198.1633635863887; Thu, 07 Oct 2021 12:44:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633635863; cv=none; d=google.com; s=arc-20160816; b=NI+P9MCi8IB/waGEPBxtAQ6OUXGdsW+Q6Tl3TWu/o5kfqQAPQEOaKPJ1c0S5Tx11Pi U/u52OxGAuQQp3tTjOByrDJiY1f8AG8dPQ3lfZdMAzqXcLaGTM95kCjbFY9xdRUdxfzt sWfmWS2sZLCHDzK8tE/GFshZF0a3/yBmZyE6WCC63jd9VM8bTNvFyvmv9iVqCUZWp6xd RHwOf7PlYGRBBxWZBUvFddDSklcc1sU4IDXIVvcznUR+305qMzlhYM5x+h4fJwyEr8aF jD7O3wmuK96O1Kqp9mfl//LztAq1/VbnXAN904TeoRkXA/ZqrU0W5JIwU/4P6ouQH99U SX1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/83RDrqHPpl87OGAurh8rfbtU/YEjkgyJAZ6Fte+y4Y=; b=HrGWaaGPWg+Y0jhYz+GpCE0nHSDDJKxmQkiUTGjwY6qAQ1OsO6Chj7FfPqE6cdwLds dohbxYrKK1ltvdMqE2PXeI7qtzMAu4mnGwOs4NImaH6k5dUO1+gbmguaTzGiDE2n7ZEe /jzOjSWGuJOoE+ALv6N+dne1bNkJHwdo5vKdUAAEmXiX43EwSQZyLI41jH9Y6NRjBfn5 pM6A8o4NYTxjujYE+ve6Fqc+C8iXSYFckkDCcrrNHUHwbwc+1jrSGg7scdCaI6zWwMb5 PUG4At+6jxe5rVvHEQxvugBM3weEhhv0CsPy4j/5hzx23iuPQE+6jSxafHNahRZojLpa eQGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=jiftm9rU; 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=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u36si273763pgl.231.2021.10.07.12.44.11; Thu, 07 Oct 2021 12:44:23 -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=@suse.com header.s=susede1 header.b=jiftm9rU; 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=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242820AbhJGRdV (ORCPT + 99 others); Thu, 7 Oct 2021 13:33:21 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:34748 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242884AbhJGRdI (ORCPT ); Thu, 7 Oct 2021 13:33:08 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id E1204200F9; Thu, 7 Oct 2021 17:31:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1633627873; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/83RDrqHPpl87OGAurh8rfbtU/YEjkgyJAZ6Fte+y4Y=; b=jiftm9rUlvRqDadj+/PG/GyTAHxCwqYmZQS//pQi+8kj7fDoqfsiM11hG0RoVgR0Su5Apc OT329neI0OF04fxbNZlPIA5H1VbCG98tjWz9FTg6jr7BLrdU27CAUaJZS4cxJK46uq+7E6 Afam4a2bEi+IY8YdyR+kmBQG45W91F4= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 2F184A3B85; Thu, 7 Oct 2021 17:31:13 +0000 (UTC) Date: Thu, 7 Oct 2021 19:31:12 +0200 From: Michal Hocko To: Suren Baghdasaryan 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, Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , 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 Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Michal Hocko SUSE Labs