Re: [PATCH] mm: anonymous shared memory naming

From: Pasha Tatashin
Date: Sun Nov 06 2022 - 08:46:30 EST


On Sun, Nov 6, 2022 at 8:34 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
>
> On Sat, Nov 05, 2022 at 02:53:42AM +0000, Pasha Tatashin wrote:
> > Since:
> > commit 9a10064f5625 ("mm: add a field to store names for private anonymous
> > memory")
> >
> > We can set names for private anonymous memory but not for shared
> > anonymous memory. However, naming shared anonymous memory just as
> > useful for tracking purposes.
> >
> > Extend the functionality to be able to set names for shared anon.
> >
> > / [anon_shmem:<name>] an anonymous shared memory mapping that has
> > been named by userspace
> >
> > Sample output:
> > share = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
> > MAP_SHARED | MAP_ANONYMOUS, -1, 0);
> > rv = prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME,
> > share, SIZE, "shared anon");
> >
> > /proc/<pid>/maps (and smaps):
> > 7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024
> > /dev/zero (deleted) [anon_shmem:shared anon]
> >
> > pmap $(pgrep a.out)
> > 254: pub/a.out
> > 000056093fab2000 4K r---- a.out
> > 000056093fab3000 4K r-x-- a.out
> > 000056093fab4000 4K r---- a.out
> > 000056093fab5000 4K r---- a.out
> > 000056093fab6000 4K rw--- a.out
> > 000056093fdeb000 132K rw--- [ anon ]
> > 00007fc8e2b4c000 262144K rw-s- zero (deleted) [anon_shmem:shared anon]
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> > ---
> > Documentation/filesystems/proc.rst | 4 +++-
> > fs/proc/task_mmu.c | 7 ++++---
> > include/linux/mm.h | 2 ++
> > include/linux/mm_types.h | 27 +++++++++++++--------------
> > mm/madvise.c | 7 ++-----
> > mm/shmem.c | 13 +++++++++++--
> > 6 files changed, 35 insertions(+), 25 deletions(-)
> >
> > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> > index 898c99eae8e4..8f1e68460da5 100644
> > --- a/Documentation/filesystems/proc.rst
> > +++ b/Documentation/filesystems/proc.rst
> > @@ -431,8 +431,10 @@ is not associated with a file:
> > [stack] the stack of the main process
> > [vdso] the "virtual dynamic shared object",
> > the kernel system call handler
> > - [anon:<name>] an anonymous mapping that has been
> > + [anon:<name>] a private anonymous mapping that has been
> > named by userspace
> > + path [anon_shmem:<name>] an anonymous shared memory mapping that has
> > + been named by userspace
>
> I expect it to break existing parsers. If the field starts with '/' it is
> reasonable to assume the rest of the string to be a path, but it is not
> the case now.

This is actually exactly why I kept the "path" part. It stays the same
as today for anon-shared memory, but prevents pmap to change
anon-shared memory from showing it as simply [anon].

Here is what we have today in /proc/<pid>/maps (and smaps):
7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024 /dev/zero (deleted)

So, the path points to /dev/zero but appended with (deleted) mark. The
pmap shows the same thing, as it is looking for leading '/' to
determine that this is a path.

With my change the above changes only when user specifically changed
the name like this:

7fc8e2b4c000-7fc8f2b4c000 rw-s 00000000 00:01 1024 /dev/zero
(deleted) [USER-SPECIFIED-NAME]

So, the path stays, the (deleted) mark stays, and a name is added.

Since this is anon memory, we can get rid of the /dev/zero path part
entirely and only print the name when the user specified one, but this
would change the output in pmap command to show all anonymous shared
memory as simply [anon].

Pasha

>
> --
> Kiryl Shutsemau / Kirill A. Shutemov