lkml.org 
[lkml]   [2011]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v6
    On Wed, Aug 31, 2011 at 18:10, Andrew Morton <akpm@linux-foundation.org> wrote:
    > On Wed, 31 Aug 2011 18:26:22 +0400 Cyrill Gorcunov <gorcunov@gmail.com> wrote:
    >> This one behaves similarly to the /proc/<pid>/fd/ one - it contains symlinks
    >> one for each mapping with file, the name of a symlink is "vma->vm_start-vma->vm_end",
    >> the target is the file. Opening a symlink results in a file that point exactly
    >> to the same inode as them vma's one.
    >>
    >> For example the ls -l of some arbitrary /proc/<pid>/map_files/
    >>
    >>  | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 -> /lib64/libc-2.5.so
    >>  | lr-x------ 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f80620000 -> /lib64/libselinux.so.1
    >>  | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 -> /lib64/libacl.so.1.1.0
    >>  | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a30000 -> /lib64/librt-2.5.so
    >>  | lr-x------ 1 root root 64 Aug 26 06:40 7f8f80a30000-7f8f80a4c000 -> /lib64/ld-2.5.so
    >
    > This particular patch introduces a distressing amount of duplication of
    > /proc/pid/maps.  The changelog should provide a really good
    > justification for doing this: why is /proc/pid/maps (and smaps!)
    > unsuitable and why cannot maps/smaps be fixed to be suitable?

    Andrew,

    This is way more useful than /proc/$PID/maps, because this allows you
    to reliably obtain an FD to an arbitrary mapped memory segment.

    EG:
    $ cp /bin/sleep ~/my-sleep
    $ ~/my-sleep 1000 & kid=$!
    $ rm ~/my-sleep
    $ mkdir ~/mapped_files
    $ for file in /proc/$kid/map_files/*; do cp "$file" ~/mapped_files/; done

    This trivially gets me copies of every mapped file, including the deleted
    "my-sleep" binary, it also trivially handles lazy-unmounted filesystems,
    chroots, namespaces, and all sorts of similar kernel cleverness.

    It's exactly the same kind of utility that /proc/$PID/fd/* has, but for
    mmap().

    With /proc/$kid/maps you simply can't work around some of those
    kinds of issues (IE: deleted files, etc).

    Cheers,
    Kyle Moffett
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-09-01 05:09    [W:0.023 / U:91.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site