Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4037291rwb; Tue, 8 Nov 2022 11:12:25 -0800 (PST) X-Google-Smtp-Source: AMsMyM7BEoSnXCOw26NpwvB6xf1OccMwaYkbCYwAOB2dolPdd2AZxdZyIFwfdied2JHgBtYlA0ZJ X-Received: by 2002:a17:906:8a6c:b0:7a8:2f09:d88d with SMTP id hy12-20020a1709068a6c00b007a82f09d88dmr53895426ejc.49.1667934745486; Tue, 08 Nov 2022 11:12:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667934745; cv=none; d=google.com; s=arc-20160816; b=B8ro7nPy/1FBpDzsqp36G/fh2C0lJk3ZzRq3XXfscInzAlv6mItJIXhchDoWosTdUq 2uG2I/TzrzRhpOBCoyZBvxMbPXqrCsad81p3bFO24W2myi9YpzYmRxImLvNn3gu2MM4L 2Ipjxj1vlKNkvxHYi4LqJhJArle38NWcJ28CrYIe+HFGN24hOgSAJgZpD/5aELOp19mE TP9i96mOuWXNExCDSYzKl50RM3PUFi898RHBwBSX4zNGvc16ZIJo19mBNH+FSoX54Gt1 rD2jmF+GpemXbJqjn87beFhIibM2UXrZ3bUsi33Ce0QHjVBXYGDySz4YlkEuVjnkORCg z1EA== 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=34xmTXahX9JOxAWp+niqcaXhO5EjSMmbu9kacIdY9GA=; b=oKeg9FFMr9soC2YuQhNvZ82fqq8RcAe3jQVqI8irqBVBBRMAqi9Lb6UjM5+LnZgToK 3pRaCFhD/rG5rz6bUsJZJAaFCRCv1uySqEQ90PcpXtIuxhOCfDPjH8a1+lHrNs2+g8Sh 4pUgf5AdqkZImYYq0xduuStG4xA56Znbyvi1EIMCIb/O/AeNpVFm0IA8YMW99Dx0EQ0o z+V3dLPmaT16MWYrSi8kgHPk0NuuabvmtcAxA8rXeb1KncZp5A2Ue90RRHJS/Chhyjdn ruLm9hMhBkBTdwuWdf8wsKaAkOqrgne9mR2v7RwScAKx3Ho+p+tLLrewxwZQipQ6DTnm Pwig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=Q7EEEYcV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id go42-20020a1709070daa00b00783d969f318si14458029ejc.253.2022.11.08.11.12.03; Tue, 08 Nov 2022 11:12:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=Q7EEEYcV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229705AbiKHSr7 (ORCPT + 91 others); Tue, 8 Nov 2022 13:47:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229613AbiKHSrZ (ORCPT ); Tue, 8 Nov 2022 13:47:25 -0500 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E8876C72C for ; Tue, 8 Nov 2022 10:45:44 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id y14so40960695ejd.9 for ; Tue, 08 Nov 2022 10:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=34xmTXahX9JOxAWp+niqcaXhO5EjSMmbu9kacIdY9GA=; b=Q7EEEYcV7XltPOfTeY+7k0wa4jo3dxm2gU1pfbspEfsVW158MhXaCQ2w7LENlv2KFN gbETXxIpwN02DzJ3Dmrp5CaxshdelWH/bKAo2om0M9pxffzXRe+udF/qr5Gbuy8Ut7zW y1aCjGRCgHWuU/JLiaKbIcpaAY6ZoCC703xNcA5l5GhztkTg/WRD22wVzrtpr3R9+SJy hEz5KtX/mhLD38qg/RPQITzxPITBH5tTUAgNObi+6TpUyjh0HGiT54mAXQ1X7/od6THg CeCrxGEiqgEzHBC6z8Sh9TDpLwOXI7kbUTgVTVSeYreXRsyw/ELOmlUegRQBCPB5RCio E/LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=34xmTXahX9JOxAWp+niqcaXhO5EjSMmbu9kacIdY9GA=; b=HjC8MTQYFOG1NTeFW4t5QgH/kHkDRR0iaSOTe0muHgdYjz3b81bYDwmZNxALh/CDSM hqf/raWwnXviO1XCrVK5w5znv0w8fvUnb8/kvyVTg6iKI0TQG4bIuUQroMeG0Idcf2wK iUg/44KAmBACMgouOS+Vfv7LPAls90Fl9k5mV22Qa6hQNo7xa5ByW3nBs1K3jn6VXTx/ HLOtgbDPuKQP+e4i/e2/5r+XIsD8c0+iCeuZRejJtVHNIM3BWhB6Z/jcfCU/ZGhwyGFi 3+1lTXDrB3qMHVrLWheeckxI3+wxNr9/k87GpmAEK0FWSpCiTx7G7rSvGtCSJLs4eVy4 qv9Q== X-Gm-Message-State: ACrzQf0Svi8OsNGveSzOED/HtXXzVrZ9RIw4EbRzHGGvwyPoPkVscDXP ZUJwAF2P6dl664oFLiPIoCRMcWGUnQWy2P4IxQ+vfg== X-Received: by 2002:a17:907:761b:b0:7a3:86dd:d330 with SMTP id jx27-20020a170907761b00b007a386ddd330mr53730091ejc.34.1667933135949; Tue, 08 Nov 2022 10:45:35 -0800 (PST) MIME-Version: 1.0 References: <20221107184715.3950621-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Tue, 8 Nov 2022 13:44:58 -0500 Message-ID: Subject: Re: [PATCH v2] mm: anonymous shared memory naming To: David Hildenbrand Cc: corbet@lwn.net, akpm@linux-foundation.org, hughd@google.com, hannes@cmpxchg.org, vincent.whitchurch@axis.com, seanjc@google.com, rppt@kernel.org, shy828301@gmail.com, paul.gortmaker@windriver.com, peterx@redhat.com, vbabka@suse.cz, Liam.Howlett@oracle.com, ccross@google.com, willy@infradead.org, arnd@arndb.de, cgel.zte@gmail.com, yuzhao@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, bagasdotme@gmail.com, kirill@shutemov.name Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, Thank you for taking a look at this change: On Tue, Nov 8, 2022 at 12:56 PM David Hildenbrand wrote: > > On 07.11.22 19:47, Pasha Tatashin wrote: > > Since: commit 9a10064f5625 ("mm: add a field to store names for private > > anonymous memory"), name for private anonymous memory, but not shared > > anonymous, can be set. However, naming shared anonymous memory just as > > ^ is > OK > > useful for tracking purposes. > > > > Extend the functionality to be able to set names for shared anon. > > > > Sample output: > > /* Create shared anonymous segmenet */ > > s/segmenet/segment/ Ok > > > anon_shmem = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, > > MAP_SHARED | MAP_ANONYMOUS, -1, 0); > > /* Name the segment: "MY-NAME" */ > > rv = prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, > > anon_shmem, SIZE, "MY-NAME"); > > > > cat /proc//maps (and smaps): > > 7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024 [anon_shmem:MY-NAME] > > What would it have looked like before? Just no additional information? Before: 7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024 /dev/zero (deleted) Pasha > > > > > Signed-off-by: Pasha Tatashin > > --- > > > [...] > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 8bbcccbc5565..06b6fb3277ab 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -699,8 +699,10 @@ static inline unsigned long vma_iter_addr(struct vma_iterator *vmi) > > * paths in userfault. > > */ > > bool vma_is_shmem(struct vm_area_struct *vma); > > +bool vma_is_anon_shmem(struct vm_area_struct *vma); > > #else > > static inline bool vma_is_shmem(struct vm_area_struct *vma) { return false; } > > +static inline bool vma_is_anon_shmem(struct vm_area_struct *vma) { return false; } > > #endif > > > > int vma_is_stack_for_current(struct vm_area_struct *vma); > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > index 500e536796ca..08d8b973fb60 100644 > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -461,21 +461,11 @@ struct vm_area_struct { > > * For areas with an address space and backing store, > > * linkage into the address_space->i_mmap interval tree. > > * > > - * For private anonymous mappings, a pointer to a null terminated string > > - * containing the name given to the vma, or NULL if unnamed. > > */ > > - > > - union { > > - struct { > > - struct rb_node rb; > > - unsigned long rb_subtree_last; > > - } shared; > > - /* > > - * Serialized by mmap_sem. Never use directly because it is > > - * valid only when vm_file is NULL. Use anon_vma_name instead. > > - */ > > - struct anon_vma_name *anon_name; > > - }; > > + struct { > > + struct rb_node rb; > > + unsigned long rb_subtree_last; > > + } shared; > > > > So that effectively grows the size of vm_area_struct. Hm. I'd really > prefer to keep this specific to actual anonymous memory, not extending > it to anonymous files. It grows only when CONFIG_ANON_VMA_NAME=y, otherwise it stays the same as before. Are you suggesting adding another config specifically for shared memory? I wonder if we could add a union for some other part of vm_area_struct where anon and file cannot be used together. > Do we have any *actual* users where we don't have an alternative? I > doubt that this is really required. > > The simplest approach seems to be to use memfd instead of MAP_SHARED | > MAP_ANONYMOUS. __NR_memfd_create can be passed a name and you get what > you propose here effectively already. Or does anything speak against it? For our use case the above does not work. We are working on highly paravirtualized virtual machines. The VMM maps VM memory as anonymous shared memory (not private because VMM is sandboxed and drivers are running in their own processes). However, the VM tells back to the VMM how parts of the memory are actually used by the guest, how each of the segments should be backed (i.e. 4K pages, 2M pages), and some other information about the segments. The naming allows us to monitor the effective memory footprint for each of these segments from the host without looking inside the guest. Pasha