Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1998180pxb; Mon, 11 Oct 2021 18:29:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7jPcY0cAr40wMYDzEEU40gWN2T7uXbrI8OZdJbINVi8FCYjYBf8/qiIc8C/c9ocTDiXmm X-Received: by 2002:a50:ff14:: with SMTP id a20mr47890875edu.81.1634002146315; Mon, 11 Oct 2021 18:29:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634002146; cv=none; d=google.com; s=arc-20160816; b=vo7HH+LqPABbKgjLSA285OmRYJbc+YzuDglsbeIaw8XgNgiIipCNqSpezInq88GbWt G0KSMW4bSbd4YayqxXB4V8MT/KkflWHhXwM93H8p534g02ZMXwujaRd/rZsb7JzpAxfW UcvX5SJ0D/roNwY1/3uzG1QsqVo85AGPUiw6FZnew+qQMSCZCcHTb+5FwErzUeBPVWXb AncpvAtT+yU/QvvH3WQP6I82G+pHJrRBe6d7NPYXAQvZVI9Y3p9pVwDyBEJqYWUU+omH AMTkiMOcgIPOyHxkNOIJ5+CnZEqifO4n+diZGrS4vSAAEVuOCEtJV3z14TgJn0O/OH7r qAWw== 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=407czVbE3e5WcfWCrJgGTmSTywUsN04juLc0rcDIHos=; b=XKg7pil8Avz0OlndCO2reGL8vixeNJ7ji6JcxtDEB7/Icn8ZzUWbuqLraP+A5bEZ8s I3Jym5upZDuoeB+9LpR16rQmTi++KwVMZhdD2WtopYwpbT+rGTTWXIpKmpmSY2Wd6iC8 GhT25AojJs0XPSX7HQPGudfceLWCk6QG/uOGWCDqw5f1zFbHB3keO0jVSDy2PifwCFdX noipTDYJxBpgQTeo/M2nyLIDqCSuQaJQybz2cCVkcp7WSwinf+dvOnFOMSbqktvtdl0d I32ywmT1gv7t4qK3Ym2b5j8xxWJs65zd1HcFNsoJVitJf/NqtkaPVYHEecc+3SIDhHMt 39iA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=TzwbmzL5; 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 h4si8443741edj.179.2021.10.11.18.28.23; Mon, 11 Oct 2021 18:29:06 -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=TzwbmzL5; 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 S235458AbhJLBVM (ORCPT + 99 others); Mon, 11 Oct 2021 21:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235366AbhJLBVF (ORCPT ); Mon, 11 Oct 2021 21:21:05 -0400 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E5C7C061570 for ; Mon, 11 Oct 2021 18:19:05 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id w10so43020225ybt.4 for ; Mon, 11 Oct 2021 18:19:05 -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=407czVbE3e5WcfWCrJgGTmSTywUsN04juLc0rcDIHos=; b=TzwbmzL5U816Bqh9kOlyCsD1sCD6dVJn2Q0kP6rcyb8lKPkHAH+ygv0sec8MKihXkD ohWYsPx597UOJUURiCPg8CepyKL2AjXQwvZ8979WeWLSKPtxHE5knrUhoujX7zgcuX/f E4gU92yKZxrpzWVS4cRDvqdp5VC/CfND05hjJKQc3AK5SQEodjo4wcbFwILdLwtP0k5b S7zFBs1/Jn75JjnSRsw9z2j5huA8PxzJdsHDHBlP0tpkDk9A14MjdrblhO4+htQGh/+j gvri2TKFi3Cym0kqw5rDVLaALHsHDbZG931XjBYJ3r+senO6Kw7oqEg9zq8eVuxlxMiA s0HA== 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=407czVbE3e5WcfWCrJgGTmSTywUsN04juLc0rcDIHos=; b=Y2SBt4Qol8fSPEktAtB+UMyobwFbAt3odgyXREXPBrXbU8ILzp/dPfad9poqI2glOu Swnp4ohuw74IuEoe+1BP/R2u0r9Jh6QCOKAqrAbuKUGdUxK10khHSTkiSRuKOQns34TD ZRmhc9rxlgtbrqlltnVmyRZCGYNfUMHiaYnGCO2jrL80LRn8PAR3fInHv0A12aA6rPJ7 Q8OYYAlFr24ncz27WSwxQ788r+56B440ulwtDElG7JnbOzm9CgVGM6qcZsv4iCJ/Cp+C Gpp6VZMALT+DW74+d0XbzQhHUGUJnSEq9XIVEE9pfhfXJJ9u1REsyoaMm/2vzYJVJAft rT7w== X-Gm-Message-State: AOAM531rpD0VlHaC8/3oXz+rc3yTxtQvkPiKCh9iPMMax3cHCSukcqgU f0RyWIFD9hMpJtTmVfzVnJgGwNAxD4qMWPFkFqaMig== X-Received: by 2002:a25:552:: with SMTP id 79mr24303168ybf.202.1634001543876; Mon, 11 Oct 2021 18:19:03 -0700 (PDT) MIME-Version: 1.0 References: <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> <202110071111.DF87B4EE3@keescook> <202110081344.FE6A7A82@keescook> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 11 Oct 2021 18:18:52 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Michal Hocko Cc: Kees Cook , Pavel Machek , Rasmus Villemoes , David Hildenbrand , John Hubbard , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 11, 2021 at 1:36 AM Michal Hocko wrote: > > On Fri 08-10-21 13:58:01, Kees Cook wrote: > > - Strings for "anon" specifically have no required format (this is good) > > it's informational like the task_struct::comm and can (roughly) > > anything. There's no naming convention for memfds, AF_UNIX, etc. Why > > is one needed here? That seems like a completely unreasonable > > requirement. > > I might be misreading the justification for the feature. Patch 2 is > talking about tools that need to understand memeory usage to make > further actions. Also Suren was suggesting "numbering convetion" as an > argument against. > > So can we get a clear example how is this being used actually? If this > is just to be used to debug by humans than I can see an argument for > human readable form. If this is, however, meant to be used by tools to > make some actions then the argument for strings is much weaker. The simplest usecase is when we notice that a process consumes more memory than usual and we do "cat /proc/$(pidof my_process)/maps" to check which area is contributing to this growth. The names we assign to anonymous areas are descriptive enough for a developer to get an idea where the increased consumption is coming from and how to proceed with their investigation. There are of course cases when tools are involved, but the end-user is always a human and the final report should contain easily understandable data. IIUC, the main argument here is whether the userspace can provide tools to perform the translations between ids and names, with the kernel accepting and reporting ids instead of strings. Technically it's possible, but to be practical that conversion should be fast because we will need to make name->id conversion potentially for each mmap. On the consumer side the performance is not as critical, but the fact that instead of dumping /proc/$pid/maps we will have to parse the file, do id->name conversion and replace all [anon:id] with [anon:name] would be an issue when we do that in bulk, for example when collecting system-wide data for a bugreport. I went ahead and implemented the proposed userspace solution involving tmpfs as a repository for name->id mapping (more precisely filename->inode mapping). Profiling shows that open()+fstat()+close() takes: - roughly 15 times longer than mmap() with 1000 unique names each being reused 50 times. - roughly 3 times longer than mmap() with 100 unique names each being reused 500 times. This is due to lstat() optimization suggested by Rasmus which avoids open() and close(). For comparison, proposed prctl() takes roughly the same amount of time as mmap() and does not depend on the number of unique names. I'm still evaluating the proposal to use memfds but I'm not sure if the issue that David Hildenbrand mentioned about additional memory consumed in pagecache (which has to be addressed) is the only one we will encounter with this approach. If anyone knows of any potential issues with using memfds as named anonymous memory, I would really appreciate your feedback before I go too far in that direction. Thanks, Suren. > -- > Michal Hocko > SUSE Labs