Re: [resend][PATCH v9 2/3] /proc/PID/status: show all sets of pid according to ns

From: Nathan Scott
Date: Tue Feb 03 2015 - 20:12:22 EST


Hi Chen, Eric,

Eric W. Biederman <ebiederm@xxxxxxxxxxxx> writes:
> Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx> writes:
> > If some issues occurred inside a container guest, host user
> > could not know which process is in trouble just by guest pid:
> > [...]
> > Acked-by: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>
> > Tested-by: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>
> >
> > Signed-off-by: Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx>
>
> Acked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
>
> At a quick review and read through this looks good. Once I finish
> clearing the security bug fixes from my tree I will see about picking
> this up.

I recently came across a need for this patch so I just wanted to
say thanks and since I've used it a fair bit feel free to add:

Tested-by: Nathan Scott <nathans@xxxxxxxxxx>

One small tweak you could make is to drop the extra whitespace
from those new seq_printf calls - "\t%d " has a trailing space
that isn't needed.

Also there's proc status docs below Documentation/ that should be
updated for these changes. They are slightly out-of-date already
and there's a few typos in the vicinity - something like this may
do the trick though ... ? (will need to be updated at merge time
with the correct kernel version)


docs: add missing and new /proc/PID/status file entries, fix typos

Signed-off-by: Nathan Scott <nathans@xxxxxxxxxx>

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index aae9dd1..457cebd 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -197,12 +197,12 @@ contains details information about the process itself. Its fields are
explained in Table 1-4.

(for SMP CONFIG users)
-For making accounting scalable, RSS related information are handled in
-asynchronous manner and the vaule may not be very precise. To see a precise
+For making accounting scalable, RSS related information are handled in an
+asynchronous manner and the value may not be very precise. To see a precise
snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table.
It's slow but very precise.

-Table 1-2: Contents of the status files (as of 2.6.30-rc7)
+Table 1-2: Contents of the status files (as of 3.20.0)
..............................................................................
Field Content
Name filename of the executable
@@ -210,6 +210,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7)
in an uninterruptible wait, Z is zombie,
T is traced or stopped)
Tgid thread group ID
+ Ngid NUMA group ID (0 if none)
Pid process id
PPid process id of the parent process
TracerPid PID of process tracing this process (0 if not)
@@ -217,6 +218,10 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7)
Gid Real, effective, saved set, and file system GIDs
FDSize number of file descriptor slots currently allocated
Groups supplementary group list
+ NStgid descendant namespace thread group ID hierarchy
+ NSpid descendant namespace process ID hierarchy
+ NSpgid descendant namespace process group ID hierarchy
+ NSsid descendant namespace session ID hierarchy
VmPeak peak virtual memory size
VmSize total program size
VmLck locked memory size

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