On Wed, Aug 31, 2011 at 18:10, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 31 Aug 2011 18:26:22 +0400 Cyrill Gorcunov <gorcunov@xxxxxxxxx> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
