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 0AC3AC433F5 for ; Tue, 12 Oct 2021 18:52:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E66E26101D for ; Tue, 12 Oct 2021 18:52:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233902AbhJLSy6 (ORCPT ); Tue, 12 Oct 2021 14:54:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232502AbhJLSy4 (ORCPT ); Tue, 12 Oct 2021 14:54:56 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A71E5C061745 for ; Tue, 12 Oct 2021 11:52:54 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id n65so688498ybb.7 for ; Tue, 12 Oct 2021 11:52:54 -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=u/2ikoEtS8dYmYHS2doDaEJiyDh/95oR0B9sccPpzdk=; b=Vyyz0+FLDpJzrNSDS/uxgo1+Hm4MZB6FEECufC2oZe6BpSfY+2lQ9V1GDsPekCKA1Y ibVu34ybCGuGun1lKL05DEmpThaQFlAOKMjGPxFH862ZDidj/rscSI2TnPPISvZpzdDq LQPmKnwjhtdCt5hY31SJZuvA1n4iV9cF3qpN20fbGHfZrgRORPR8UPAtGgkArQiC3pZ4 dx9d01Fv1wuJ3GlTMrzZSFHZetnu2VX4wEX3/lRxqKu/ajoRZRZbpNqhCuvg9RVGHW9l 5W45uAAwFYd1aQd4mldwrYo5KJ8u4mbNZtQXjAp50QBiDmVr5J8hNiPGxjYGNmjTdUGA fOhw== 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=u/2ikoEtS8dYmYHS2doDaEJiyDh/95oR0B9sccPpzdk=; b=zeaovo6oNHjgInL+jjDePg/yl17USFayXwVcaksRyfp8Gi8+D8IufcSpMVLM/9sU0N wFbYVKMEAfIM/JHeqfACobfUCKYvU9nZiBBzUQ1BpZTcDtkn8EYOBqWpaDJM+P0QeoTx OfocuZn+djW4mXVHiRJ9Dr9jk6NaZcuRi+2V3JBpwHlposnJWTsxpVahbGkuq8zZl1kp sBjs+Kodu0cNfR+Qe4YSGn+OxKukD4MAgKqSquUnldN1d9yBwC8XgYNshAaNVr5jBJUT fqlDonYZc9hjVFBkBvHx9Gt0EedfJXdEd+L6YphVwjrLNVelJ6pB84auWJtc3PsE1sNX Bwwg== X-Gm-Message-State: AOAM533xSJ3pQefldJF1yflUgQbdDu4gmt5BKrFl9G1ttLDNUCpet/R1 43/aFaDs/vhFN/D1ab5soTg5fRV5w7Jpqnki1x0yFw== X-Google-Smtp-Source: ABdhPJxAnjPTZ0/jHIA+UD3BTsvIofJny5fJqTHY79M0MwPby/nq2TnpuLlyL4tajdUpaaG2PpH5UTEuQiDn3qgZ3VI= X-Received: by 2002:a05:6902:120e:: with SMTP id s14mr33588722ybu.161.1634064773432; Tue, 12 Oct 2021 11:52:53 -0700 (PDT) MIME-Version: 1.0 References: <202110071111.DF87B4EE3@keescook> <202110081344.FE6A7A82@keescook> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 12 Oct 2021 11:52:42 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Johannes Weiner 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, =?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 , Tim Murray Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 12, 2021 at 11:26 AM Johannes Weiner wrote: > > 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. True, and that's why I mentioned that it's not as critical as the efficiency at mmap() time. In any case, if we could avoid translations at all that would be ideal. > > 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. You still have to retrieve that tag from the kernel to record it in your db, so this would still require some syscall, no? > (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.) Overall, I think keeping the kernel out of this and letting it treat this tag as a cookie which only userspace cares about is simpler. Unless you see other uses where kernel's involvement is needed.