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 205D2C433EF for ; Tue, 12 Oct 2021 18:52:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BB9C260527 for ; Tue, 12 Oct 2021 18:52:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BB9C260527 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 50A27940007; Tue, 12 Oct 2021 14:52:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E00B900002; Tue, 12 Oct 2021 14:52:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CF28940007; Tue, 12 Oct 2021 14:52:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 2ED54900002 for ; Tue, 12 Oct 2021 14:52:55 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E53D939477 for ; Tue, 12 Oct 2021 18:52:54 +0000 (UTC) X-FDA: 78688682268.33.A297382 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf29.hostedemail.com (Postfix) with ESMTP id 9B5819000263 for ; Tue, 12 Oct 2021 18:52:54 +0000 (UTC) Received: by mail-yb1-f171.google.com with SMTP id v195so848752ybb.0 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=cwnDrcN2ZkZBgD6ghQ76AZ0qTm68gRHaf1D4ac1DIf55UBru3bOk4YkeHYG9kz30q3 4EmBIvyBpJJpocrZQsXvtrNNaZG5hSi9aEqF0YxjfWERPMJ9U5smpjMb3txA8KFkd4h5 zGZELCKZcl9u6M0EfEGgVsdNQUL7yMDgen2yIXnN/sLI1hW+qPWh4dt2Otw3KyCpQ46f DsuomvD4bHkYc+J5uXSL1wMG2l5bM/2H5MCf/eckHlnkjDGbR8A87tjzX6mJgIpPsFzO EWrwdOaG8PiULNwm/wALaE8OYIBqAg9XPX5s8bIOgsQKV5wrf8rT4PqxL+P/xBuHv3/a IDNg== X-Gm-Message-State: AOAM530FvGnFjxD07Z0veYhvcNA8F5qNpvRgB5t30/5lqZeJZ4J9jmOg 9b0uLEGosqSoRqkmZcnqwib3O5D5H+pGqBVI4fa2eA== 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" X-Rspamd-Queue-Id: 9B5819000263 X-Stat-Signature: mrkbbohb5fr5imwiddmhbnb8dy8jjck7 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Vyyz0+FL; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-HE-Tag: 1634064774-494933 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 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.