linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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



  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