lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+CK2bDK=oUYM-HZsYfZoq_n5BQMGpysMq395WK78r+SwYk99A@mail.gmail.com>
Date:   Sun, 6 Nov 2022 08:45:44 -0500
From:   Pasha Tatashin <pasha.tatashin@...een.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     corbet@....net, akpm@...ux-foundation.org, hughd@...gle.com,
        hannes@...xchg.org, david@...hat.com, vincent.whitchurch@...s.com,
        seanjc@...gle.com, rppt@...nel.org, shy828301@...il.com,
        paul.gortmaker@...driver.com, peterx@...hat.com, vbabka@...e.cz,
        Liam.Howlett@...cle.com, ccross@...gle.com, willy@...radead.org,
        arnd@...db.de, cgel.zte@...il.com, yuzhao@...gle.com,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: anonymous shared memory naming

On Sun, Nov 6, 2022 at 8:34 AM Kirill A. Shutemov <kirill@...temov.name> 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@...een.com>
> > ---
> >  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ