Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1519689pxb; Thu, 7 Oct 2021 09:18:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBdKI8Nf66mG8M51G9pQBACEwzK0f0tZ7WmuVw8Qeo1hxpQHalGIq6Dfru8d3XebKbxxXa X-Received: by 2002:a05:600c:154f:: with SMTP id f15mr5726953wmg.92.1633623533801; Thu, 07 Oct 2021 09:18:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633623533; cv=none; d=google.com; s=arc-20160816; b=TZ5IZc+1lg2MSoV+m23Bxi+ujv0hKVhwLHxRI7mrA7bNSYGUZU+I5tBoVTKCdpDM4I 9dj0lruauJRN4HSjEuzrSK5dRZO7bY6x56FfIm8v4xARC+tBEhq4MXLy32ZsAz2ZVPBe KdVSTyusJ2KUvxqUs+MOWmKtW4dYxRdqgWzbi78z3hQlJGFEIeAIeWL8bpYl9Bt5XYpT Qqt9qbihPM22owfJyzQaVvBpC64LWl0IZUO92q+c+CWGB1niSfEW3OoU/mhaz1/oSP28 nHfNk39Bslx631eQXQk5igC1+Oql+oiKoH3H1j7/d06AMMFf8sbPcJYA7FtjxX/LJKli jf8A== 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=idsd5mctgolloTq522mlXra0iGlPTwRxJgNy/gnn+wQ=; b=Qru+OC9k65XF2WSDN7K3I03aoShfLTKbmg/YW3TltCjYrHjJGamwh5Im9464Qu9PWt w1F5C5nlat8PJel2Y1fJiVg/lw3Hg9vqLZ6/VUTZ3kGydAp/4SfQI2d5zK3oqgyHROg4 k1Jn3YAuZOnXU0HhS27EViGDVzuD2K5GWzYOx9eLvwoendXReZjYb2aQ4Af3FD89Fein 7uVApPDsSjSf1a/4tDHO2gPyDhfUl7qYJxIUO7jVnz7RMc/reGWqBYnOwkf+wD5f8WM7 uOLmEs1mitrjJrY9zW+n0Ho/nNQyuXVp6L+VfQbfeo7eZia5EyhTmJPuObkC3DOeVGoq SMMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kXYYisjK; 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 23si860834edv.54.2021.10.07.09.18.29; Thu, 07 Oct 2021 09:18:53 -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=kXYYisjK; 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 S235232AbhJGQGQ (ORCPT + 99 others); Thu, 7 Oct 2021 12:06:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242425AbhJGQGP (ORCPT ); Thu, 7 Oct 2021 12:06:15 -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 4B742C061746 for ; Thu, 7 Oct 2021 09:04:21 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id h2so14385393ybi.13 for ; Thu, 07 Oct 2021 09:04:21 -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=idsd5mctgolloTq522mlXra0iGlPTwRxJgNy/gnn+wQ=; b=kXYYisjK1xNhb3JOoFrAhJNoJOkeGU9DaJyxG2fvBrDNVdaOmc6g3jNa//6kthDqeG zQxMuDKUOyw9KSRu50Aj3rQlprQSM3QiPHY/4v/gfs/jtmBqZD25r1t8w2gpbY224vgR xOMfkCe7Yx1sFQvabb2bpd3/Zfqv1ZftfZMd+RgN9itmzWRuej+FJ9ZqMlTnWcL0qy1E MXMJUEoVQnMz3Qoxc3FVeY2vG5GGww+t6HbNg1oqLu41PlRbignDbA32LJ+u3yp3Ywe5 GYnqJsOJVUBfC+PJaNS6AhT4w3FcDiuVHdNrQuBDl/qY7WauvSAvbPtSzjCehbYqkNhM AowA== 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=idsd5mctgolloTq522mlXra0iGlPTwRxJgNy/gnn+wQ=; b=P7jso7u45xq5q+2pnvD7JRdo2G7kwbIvDc8ceaOqonvR7aYqkIpE6OOtrAZvX2vqqE giWqz1k4Oo4+76K7BPVyiElTiQnYxfGxIiwb4LzNU+IAGr6+rILS4hWmh1lsIuJXYOZe jCnKN8kBAVYYE6qUslqT3Ftg728ZxP4EkW7voVMeIIaTWXxXSei8DR+r/3IDNAU3ofuF YycwIosN6mLZMhwHOFamkjGyDGF90lQ+RnRI+OUR02cgxs8TOsBRsWyooCGgLCOMzVQU YcUxJSPAsgeTVzSQrJdiwtElKEaCQEVYjEJJif2Zx3ChraBS4/gtnNbx2DLeGq+vFU+I jcOQ== X-Gm-Message-State: AOAM532D0clmly8CQ7v2uCxvjTTvuuXqZ+rMzXjJERZjV5oGlusJ7Rqb LuJIM1FX2HnuvY5NkDU9nhqzZjOKBIIDdVLhTAw3tw== X-Received: by 2002:a25:5646:: with SMTP id k67mr5923693ybb.127.1633622660245; Thu, 07 Oct 2021 09:04:20 -0700 (PDT) MIME-Version: 1.0 References: <20211005200411.GB19804@duo.ucw.cz> <6b15c682-72eb-724d-bc43-36ae6b79b91a@redhat.com> <20211006175821.GA1941@duo.ucw.cz> <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> In-Reply-To: <20211007101527.GA26288@duo.ucw.cz> From: Suren Baghdasaryan Date: Thu, 7 Oct 2021 09:04:09 -0700 Message-ID: Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Pavel Machek Cc: Rasmus Villemoes , Michal Hocko , David Hildenbrand , John Hubbard , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Kees Cook , 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 Thu, Oct 7, 2021 at 3:15 AM Pavel Machek wrote: > > Hi! > > > >> Hmm, so the suggestion is to have some directory which contains files > > >> representing IDs, each containing the string name of the associated > > >> vma? Then let's say we are creating a new VMA and want to name it. We > > >> would have to scan that directory, check all files and see if any of > > >> them contain the name we want to reuse the same ID. > > > > > > I believe Pavel meant something as simple as > > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > > > $ touch $YOUR_FILE > > > $ stat -c %i $YOUR_FILE Ah, ok, now I understand the proposal. Thanks for the clarification! So, this would use filesystem as a directory for inode->name mappings. One rough edge for me is that the consumer would still need to parse /proc/$pid/maps and convert [anon:inode] into [anon:name] instead of just dumping the content for the user. Would it be acceptable if we require the ID provided by prctl() to always be a valid inode and show_map_vma() would do the inode-to-filename conversion when generating maps/smaps files? I know that inode->dentry is not one-to-one mapping but we can simply output the first dentry name. WDYT? > > > > So in terms of syscall overhead, that would be open(..., O_CREAT | > > O_CLOEXEC), fstat(), close() - or one could optimistically start by > > You could get to two if you used mkdir instead of open. > > > > YOUR_IDS_DIR can live on a tmpfs and you can even implement a policy on > > > top of that (who can generate new ids, gurantee uniqness etc...). > > > > > > The above is certainly not for free of course but if you really need a > > > system wide consistency when using names then you need some sort of > > > central authority. How you implement that is not all that important > > > but I do not think we want to handle that in the kernel. Ideally it would be great if $YOUR_IDS_DIR/my_string_name entries could be generated by the kernel in response to userspace calling prctl(..., name) but I haven't looked into complexity of doing that, so I would not propose that at this point. Thanks for sharing the ideas! Suren. > > > > IDK. If the whole thing could be put behind a CONFIG_ knob, with _zero_ > > overhead when not enabled (and I'm a bit worried about all the functions > > that grow an extra argument that gets passed around), I don't mind the > > string interface. But I don't really have a say either way. > > If this is ever useful outside of Android, eventually distros will > have it enabled. > > Best regards, > Pavel > -- > http://www.livejournal.com/~pavelmachek