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 8D74CC433FE for ; Tue, 12 Oct 2021 18:26:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2343860E9C for ; Tue, 12 Oct 2021 18:26:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2343860E9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id AA612940007; Tue, 12 Oct 2021 14:26:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5471900002; Tue, 12 Oct 2021 14:26:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91C50940007; Tue, 12 Oct 2021 14:26:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 833A3900002 for ; Tue, 12 Oct 2021 14:26:47 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 435BB82499A8 for ; Tue, 12 Oct 2021 18:26:47 +0000 (UTC) X-FDA: 78688616454.27.DDA2821 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by imf28.hostedemail.com (Postfix) with ESMTP id C6307900009E for ; Tue, 12 Oct 2021 18:26:46 +0000 (UTC) Received: by mail-qk1-f182.google.com with SMTP id 77so19057680qkh.6 for ; Tue, 12 Oct 2021 11:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UTuSq4pUiA+lEbguKdAALIojpT52sPH6If+YjkHNeQk=; b=0VGUhp8rfAYh5i2ID6ejSb31wvZKXwBP2ikdcYiyNZDLb52wiJKT8E8mZ7D6P2T2aO T8YT3281DZm0X7na/m1UZbkOy8LfbYQJrgo6GjyLk7r1unw/EwelmR89447vwuH+PcV6 GWeavNsaJ0KokPwmAqJpZN6iXbTM7YvKyEYMQ9xdSLic6ENDAhIbilbAlUhcZkOhXWPM EPsBasZbFrlPaLp0UiKdCtM1ULi6hGSvN/BbZaNBbGoayHRrZsCVtXJBz9Fb0evZfcYZ MOiTknGB2T05zFSD0EPWC/e1AQYKxrCITmCoRLSV9z+s2+R+7en/O5gvFz7UEac7GEfW cPkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UTuSq4pUiA+lEbguKdAALIojpT52sPH6If+YjkHNeQk=; b=ehjDy5x8sAqFJ9XRsJaczE2II66Qnci2O8bjsms8ongR9TOObVw8VdOidJXI+yuPRp F2kGnFOdWy9ws+TzNwEWVcfdPCScPVllSKcvSGVOOw3tOgY1x2IVJWxKvIHo3PAruOR5 +MfQ8QnG46iT+lV7yFDOlZdwnPwDkKwQ8C9GMbTJhHMom9sZHpnxWO9piprac5xXzRPg sNQAuIgs5jA7gk5X7WpVuvFsSGd19tokr8/0eVUX4QlW/kR1W1+tz+dzLTear6T5O+oP f3DWLmYsltZNFHZUq3j9oj+8QYhYzFl1W3oKSPuYF3dARIVJhh3QutvtfJcug7wx+CiB XNtw== X-Gm-Message-State: AOAM532LIGT4Kjl04c83V5VxvBxLRa+32C+8ySLRWW5jiesaJB6KKdBc D/fJOzWs1qVOyFKoocmvGi7lRA== X-Google-Smtp-Source: ABdhPJyIGKWkZNgBeo4x1xYLqMnW+mHsUQ4qQbb22DOfdPjwgy6Sbpkn6u/PRV2Qrzzp5A7pP2Ve4A== X-Received: by 2002:a05:620a:1a12:: with SMTP id bk18mr11319299qkb.266.1634063206025; Tue, 12 Oct 2021 11:26:46 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id b20sm6579357qtt.2.2021.10.12.11.26.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 11:26:45 -0700 (PDT) Date: Tue, 12 Oct 2021 14:26:44 -0400 From: Johannes Weiner To: Suren Baghdasaryan Cc: Michal Hocko , 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 , 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 , Tim Murray Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting Message-ID: References: <202110071111.DF87B4EE3@keescook> <202110081344.FE6A7A82@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=0VGUhp8r; spf=pass (imf28.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.182 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C6307900009E X-Stat-Signature: frjkazp711yzq8dxbrn1bracobeyf6j8 X-HE-Tag: 1634063206-712063 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 Mon, Oct 11, 2021 at 10:36:24PM -0700, Suren Baghdasaryan wrote: > On Mon, Oct 11, 2021 at 8:00 PM Johannes Weiner wrote: > > > > On Mon, Oct 11, 2021 at 06:20:25PM -0700, Suren Baghdasaryan wrote: > > > On Mon, Oct 11, 2021 at 6:18 PM Suren Baghdasaryan wrote: > > > > > > > > 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. > > > > Is that something you need to do client-side? Or could the bug tool > > upload the userspace-maintained name:ids database alongside the > > /proc/pid/maps dump for external processing? > > You can generate a bugreport and analyze it locally or submit it as an > attachment to a bug for further analyzes. > Sure, we can attach the id->name conversion table to the bugreport but > either way, some tool would have to post-process it to resolve the > ids. If we are not analyzing the results immediately then that step > can be postponed and I think that's what you mean? If so, then yes, > that is correct. Right, somebody needs to do it at some point, but I suppose it's less of a problem if a developer machine does it than a mobile device. One advantage of an ID over a string - besides not having to maintain a deduplicating arbitrary string storage in the kernel - is that we may be able to auto-assign unique IDs to VMAs in the kernel, in a way that we could not with strings. You'd still have to do IPC calls to write new name mappings into your db, but you wouldn't have to do the prctl() to assign stuff in the kernel at all. (We'd have to think of a solution of how IDs work with vma merging and splitting, but I think to a certain degree that's policy and we should be able to find something workable - a MAP_ID flag, using anon_vma as identity, assigning IDs at mmap time and do merges only for protection changes etc. etc.)