On 06/26/2013 04:05:01 PM, Andy Lutomirski wrote:
I was surprised to discover that a process can have a parent that
isn't
a thread group leader. (The usual ppid interfaces hide this, but the
children list exposes it.)
Signed-off-by: Andy Lutomirski <[email protected]>
Cc: Cyrill Gorcunov <[email protected]>
Cc: Oleg Nesterov <[email protected]>
---
Documentation/filesystems/proc.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index fd8d0d5..205796a 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1623,6 +1623,12 @@ This file provides a fast way to retrieve
first level children pids
of a task pointed by <pid>/<tid> pair. The format is a space
separated
stream of pids.
+This really is a per-thread list. If a process's parent is a thread,
+then that process will appear in that thread's children list. (This
+means that, for any pid, /proc/pid/task/*/children are disjoint
lists.)
+This may be surprising, as /proc/pid/status's PPid field is parent's
+tgid as opposed to the parent's tid.
I've read this twice and still don't quite understand what it's saying.
(Possibly I need more than 3 hours of sleep.)
It sounds like you're saying a thread can fork() and exec() and this
makes proc look weird, because the ppid pooints to the thread group
leader and not the thread, but the proc info listing us as a child
belongs to the thread?
Is this a bug that should be fixed rather than documented? (Showing the
right ppid for this corner case?)
Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
