proc.5: Add info about /proc/[pid]/map_files directory (v2)
PATCH 1/1 proc.5: Add info about /proc/[pid]/map_files directory (v2)
It was added into Linux v3.3 and provides info about files being mmap-ed in a way _very_ similar to how /proc/[pid]/fd works. Thus I thought that the best place for the map_files' doc is where where the fd's doc is.
v2: Added examples of how links look like and dependency on kernel config option CONFIG_CHECKPOINT_RESTORE.
---
man5/proc.5 +36 -0
@@ -286,6 +286,42 @@ Thus the example command above could be written as: .RB "$" " foobar \-i /dev/stdin \-o /dev/stdout ..." .fi .in +.TP +.IR /proc/[pid]/map_files/ " (since kernel 3.3) +This subdirectory contains entries corresponding to memory mapped +files (see +.BR mmap (2)). +Entries are named by memory region start and end pair, +and are symbolic links to the files themselves. Like this +.in +4n +.nf + +.RB "$" " ls -l /proc/self/map_files/" +lr--------. 1 root root 64 Apr 16 21:31 3252e00000-3252e20000 -> /usr/lib64/ld-2.15.so +\&... +.fi +.in + +Although these entries are present for memory regions that were +mapped with +.BR MAP_FILE +flag, the way anonymous shared memory (regions created with +.B MAP_ANON | MAP_SHARED +flags) +is implemented in Linux +makes such regions also appear on this directory. In that case +the target file would be the deleted /dev/zero one: +.in +4n +.nf + +.RB +lrw-------. 1 root root 64 Apr 16 21:33 7fc075d2f000-7fc075e6f000 -> /dev/zero (deleted) +.fi +.in + +This directory appears only if the +.B CONFIG_CHECKPOINT_RESTORE +kernel configuration option is enabled. .\" FIXME Describe /proc/[pid]/loginuid .\" Added in 2.6.11; updating requires CAP_AUDIT_CONTROL .\" CONFIG_AUDITSYSCALL
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Pavel Emelyanov
It was added into Linux v3.3 and provides info about files being mmap-ed in a way _very_ similar to how /proc/[pid]/fd works. Thus I thought that the best place for the
map_files' doc is where where the fd's doc is.v2: Added examples of how links look like and dependency on kernel config option
CONFIG_CHECKPOINT_RESTORE.Signed-off-by Pavel Emelyanov <[email protected]>
Thanks Pavel. Applied.
Cheers,
Michael
Quoted 39 lines
---
man5/proc.5 +29
-0@@ -286,6 +286,42 @@ Thus the example command above could be written as: .RB "$" " foobar \-i /dev/stdin \-o /dev/stdout ..." .fi .in +.TP +.IR /proc/[pid]/map_files/ " (since kernel 3.3) +This subdirectory contains entries corresponding to memory mapped +files (see +.BR mmap (2)). +Entries are named by memory region start and end pair, +and are symbolic links to the files themselves. Like this +.in +4n +.nf + +.RB "$" " ls -l /proc/self/map_files/" +lr--------. 1 root root 64 Apr 16 21:31 3252e00000-3252e20000 -> /usr/lib64/ld-2.15.so +\&... +.fi +.in + +Although these entries are present for memory regions that were +mapped with +.BR MAP_FILE +flag, the way anonymous shared memory (regions created with +.B MAP_ANON | MAP_SHARED +flags) +is implemented in Linux +makes such regions also appear on this directory. In that case +the target file would be the deleted /dev/zero one: +.in +4n +.nf + +.RB
man5/proc.5 Thus the example command above could be written as: · line 327
Quoted 10 lines
man5/proc.5 +7
-0+lrw-------. 1 root root 64 Apr 16 21:33 7fc075d2f000-7fc075e6f000 -> /dev/zero (deleted) +.fi +.in + +This directory appears only if the +.B CONFIG_CHECKPOINT_RESTORE +kernel configuration option is enabled. .\" FIXME Describe /proc/[pid]/loginuid .\" Added in 2.6.11; updating requires CAP_AUDIT_CONTROL .\" CONFIG_AUDITSYSCALL
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html