From: David Hildenbrand <david@redhat.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>,
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
Subject: Re: [PATCH v2] mm: anonymous shared memory naming
Date: Tue, 8 Nov 2022 18:56:48 +0100 [thread overview]
Message-ID: <e94ac231-7137-010c-2f2b-6a309c941759@redhat.com> (raw)
In-Reply-To: <20221107184715.3950621-1-pasha.tatashin@soleen.com>
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/<pid>/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 <pasha.tatashin@soleen.com>
> ---
[...]
> 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
next prev parent reply other threads:[~2022-11-08 17:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 18:47 Pasha Tatashin
2022-11-08 17:56 ` David Hildenbrand [this message]
2022-11-08 18:44 ` Pasha Tatashin
2022-11-09 10:11 ` David Hildenbrand
2022-11-15 1:36 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e94ac231-7137-010c-2f2b-6a309c941759@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@Oracle.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bagasdotme@gmail.com \
--cc=ccross@google.com \
--cc=cgel.zte@gmail.com \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kirill@shutemov.name \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=paul.gortmaker@windriver.com \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=shy828301@gmail.com \
--cc=vbabka@suse.cz \
--cc=vincent.whitchurch@axis.com \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox