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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D157FC4332F for ; Tue, 8 Nov 2022 17:56:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C0198E0009; Tue, 8 Nov 2022 12:56:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 370578E0001; Tue, 8 Nov 2022 12:56:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 237A88E0009; Tue, 8 Nov 2022 12:56:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1437D8E0001 for ; Tue, 8 Nov 2022 12:56:57 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DCFB31A0411 for ; Tue, 8 Nov 2022 17:56:56 +0000 (UTC) X-FDA: 80111030832.13.D9DD0CC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 9047B120002 for ; Tue, 8 Nov 2022 17:56:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667930216; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KC+QOAZ2Rjsc33WuLf5AORtVReDw8ySdynapXv7DDmc=; b=aZJ3DWU6z/EAKzh65MrdcSavMIowMY65WKMz1SHEnpMx7zI/ZOPV2df+myO+tYYetCJwo0 KiVOwjRobQD9S2bk5FBxaebamF83sJ/8YeWquFfmWTQBM3kiy4oo5xLi1QnWRJvRsDzwc7 IX+pTJtYLosqaaggDCzDQvqpSoWMWGs= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-73-MAlRQbCMN12-5yJOFYGlDA-1; Tue, 08 Nov 2022 12:56:52 -0500 X-MC-Unique: MAlRQbCMN12-5yJOFYGlDA-1 Received: by mail-wm1-f72.google.com with SMTP id ay40-20020a05600c1e2800b003cf8aa16377so7188328wmb.7 for ; Tue, 08 Nov 2022 09:56:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KC+QOAZ2Rjsc33WuLf5AORtVReDw8ySdynapXv7DDmc=; b=j86o3d4F44nOEIQmb9dC42b7ezAmQrGSMCun4NSqundV/6kXAHrT46M2LO0bJylVJX rGvK9MPcPIbVo3QY/n5+LwAZZmNiZjNg6ZcRZaBQQ2H2hpE+pTzRH+pDIUeRki4tmtpM xbKoum3f8yMYdwUNemJ10T7d65qoOpDMzbeuSO2sgQdRnmhY8UXrmhq++UOS6LYTx0yJ OcXmvz+eSehj8F8xCsN0m4Wa4cGhQG1n7nKji1pyOhMPkb8xpfJB0fSKmX3w2415gbif lI+S9SzZm8m7GB4WVShrDl3txxMa4F9EJ+L9IDGn7uBhTnqxH00htF/gm4rXXTKOFBIx dShw== X-Gm-Message-State: ACrzQf1dA+3zxkuRBpDFWQg2Pu62EbCtlqL3j035efyiDxk2919fenn3 DVNKbon+n18ay1O9rH9z2SF+n3ebbmvhH7yYFT7jNt9doIAqDaWtN/h/4/GHTMTuGWtVC1WhkMM ctF2c7Ro6vIQ= X-Received: by 2002:a05:600c:3494:b0:3cf:8ed7:7124 with SMTP id a20-20020a05600c349400b003cf8ed77124mr615945wmq.140.1667930211424; Tue, 08 Nov 2022 09:56:51 -0800 (PST) X-Google-Smtp-Source: AMsMyM6VUBcqMmBhSgArgPVMY9CQPRgOY/M6ncMhTHXwRtOanYZY7VA2pKJUh5kwU2FYxjJXG0Z1kA== X-Received: by 2002:a05:600c:3494:b0:3cf:8ed7:7124 with SMTP id a20-20020a05600c349400b003cf8ed77124mr615936wmq.140.1667930211007; Tue, 08 Nov 2022 09:56:51 -0800 (PST) Received: from ?IPV6:2003:cb:c708:db00:6510:da8d:df40:abbb? (p200300cbc708db006510da8ddf40abbb.dip0.t-ipconnect.de. [2003:cb:c708:db00:6510:da8d:df40:abbb]) by smtp.gmail.com with ESMTPSA id h19-20020a05600c351300b003b4ff30e566sm34771742wmq.3.2022.11.08.09.56.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 09:56:50 -0800 (PST) Message-ID: Date: Tue, 8 Nov 2022 18:56:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 To: Pasha Tatashin , 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 References: <20221107184715.3950621-1-pasha.tatashin@soleen.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2] mm: anonymous shared memory naming In-Reply-To: <20221107184715.3950621-1-pasha.tatashin@soleen.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aZJ3DWU6; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667930216; a=rsa-sha256; cv=none; b=4KeaeLIefH9h61UD6d7aGV5fQGInMxIP/YRhuexAtD6UGzA0uUT6+NkS7BVZ2R86l45AV/ EcwkO1JqsxyC1dCza+9jdpNIa1L9kk3g0HSu7civFeEnIeUiND1xPGxDTG9dz1ag1rWY0T qYGRQQLuzjJ2WXEGeL2y9Ecx79hN+yg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667930216; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KC+QOAZ2Rjsc33WuLf5AORtVReDw8ySdynapXv7DDmc=; b=N5WzAupz1ZzWEcWq0B9Ks49FHfBih2+YPUCR9Q136eBDXb9mVHzJWuouPj2fxjq9q7U/J1 Ma1pIye1WR3ZJEdy4Bh4Vdvqe+Nwg/SxZ+ibQsvH9R/Rd0HX7QUTe/n4p80l3rIhzWkdyt jYlBw4w5OcmSDa0Kt7YhTlhy40mudME= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9047B120002 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aZJ3DWU6; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: 16ax3rignxtekfzzqcm3f5dyf76obikb X-Rspam-User: X-HE-Tag: 1667930216-803126 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 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 > 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/ > 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? > > 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. 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? -- Thanks, David / dhildenb