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 8D0EEC433F5 for ; Tue, 12 Oct 2021 18:26:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74B4B60ED4 for ; Tue, 12 Oct 2021 18:26:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233793AbhJLS2v (ORCPT ); Tue, 12 Oct 2021 14:28:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232387AbhJLS2t (ORCPT ); Tue, 12 Oct 2021 14:28:49 -0400 Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCD79C061570 for ; Tue, 12 Oct 2021 11:26:47 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id bl14so6883715qkb.4 for ; Tue, 12 Oct 2021 11:26:47 -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=3ZKXlwIOgenV2GGkLszJgu8/1hFoCD265E3KK1bDeZYFXTUjmpHd8inC9VtDny74em bkH/bE4WgpsU4xrf2Y1C67p38b/ofRLBz+bhFTB2gdJwJWM0yQhE+5/ofuaKKZq5fJiv KEPZrgUOwQrQ0PxaDGNNUAzc/gR/3ghqsqS+SihbUG2Tb01oj9diVlhUEAqxQUad+RD7 fKtHfbnVou10SZI4Jhh0Ns5CHALqVY4/0YcYlYIn3Q9C9d/PfHTYTyB3sFaEHXhNsKer 9HMjgQt6Ep4jQQ7daRKgQG0x5ncwnW5v8VkQb2qdcaVnWYuUN4a4xXgbaj9Hc8oR9+hz 7G2Q== X-Gm-Message-State: AOAM530/zYBGY7jWJpwaABe02iQgbARMvu0dnz9MtWJgC36FLVrWIFe8 +qgRtPeLCbXoQFAjZrEQ6EMlZA== 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.)