[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGZ=bqLE8uJj+m-LZM1OX093M+0aE6+zxJF0o5DPHOnYX3iA5A@mail.gmail.com>
Date: Wed, 31 Aug 2011 23:07:05 -0400
From: Kyle Moffett <kyle@...fetthome.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Cyrill Gorcunov <gorcunov@...il.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Vasiliy Kulikov <segoon@...nwall.com>,
containers@...ts.osdl.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Nathan Lynch <ntl@...ox.com>,
Oren Laadan <orenl@...columbia.edu>,
Daniel Lezcano <dlezcano@...ibm.com>,
Glauber Costa <glommer@...allels.com>,
James Bottomley <jbottomley@...allels.com>,
Tejun Heo <tj@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Al Viro <viro@...iv.linux.org.uk>,
Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/
directory v6
On Wed, Aug 31, 2011 at 18:10, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Wed, 31 Aug 2011 18:26:22 +0400 Cyrill Gorcunov <gorcunov@...il.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists