On 01/04/2011 05:44 PM, Cedric Le Goater wrote:
> On 01/04/2011 05:04 PM, Daniel Lezcano wrote:
>> On 01/04/2011 12:02 AM, Mike Heffner wrote:
>>> Hi,
>>>
>>> Is it possible for a process running in a parent PID namespace to map
>>> the PID of a process running in a child's namespace from the
>>> parent->child's namespace? For example, if I span the process "myproc"
>>> with CLONE_NEWPID then a call to getpid() inside myproc will return "1"
>>> whereas in the parent's namespace that process could actually be PID
>>> "23495". I'd like to be able to know that 23495 maps to 1 in the new NS.
>>> Obviously, just mapping the first PID is straightforward since I can
>>> just look at the result of clone(). However, mapping the PIDs of
>>> processes subsequently forked from "myproc" -- in this example -- I
>>> haven't been able to figure out.
>> AFAIK, it is not possible.
>>
>> That would be very nice to show the pid<-> vpid association.
>>
>> The procfs is a good candidate to show these informations.
>>
>> That would makes sense to show the content of /proc/<pid>/status with
>> the pid relatively to the namespace.
>>
>> Let me give an example:
>>
>> Assuming the process '1234' creates a new pid namespace, and the child
>> which is '1' in the new namespace has the real pid '4321'. This one
>> mounts its /proc.
>>
>> If the process '1234' looks at /proc/4321/root/proc/1/status, it sees:
>>
>> ...
>> Tgid: 1
>> Pid: 1
>> PPid: 0
>> ...
>>
>>
>> It could be:
>>
>> ...
>> Tgid: 4321
>> Pid: 4321
>> PPid: 1234
>> ...
>>
>> as the file is inspected from the parent namespace. Of course, if the
>> file is looked from the child namespace context, we will see '1', '1'
>> and '0'.
>>
>> I suppose the patch in the kernel should very small also.
>>
>> Thoughts ?
> we use the following patch to get the pid of a task as seen from its
> pid namespace. It can be useful to identify tasks writing pids in files.
>
> Cheers,
>
> C.
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index fff6572..9a7bfde 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -337,6 +337,12 @@ static void task_cpus_allowed(struct seq_file *m, struct task
> seq_printf(m, "\n");
> }
>
> +static void task_vpid(struct seq_file *m, struct task_struct *task)
> +{
> + struct pid_namespace *ns = task_active_pid_ns(task);
> + seq_printf(m, "Vpid:\t%d\n", ns ? task_pid_nr_ns(task, ns) : 0);
> +}
> +
> int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *task)
> {
> @@ -357,6 +363,7 @@ int proc_pid_status(struct seq_file *m, struct pid_namespace *
> task_show_regs(m, task);
> #endif
> task_context_switch_counts(m, task);
> + task_vpid(m, task);
> return 0;
> }
Right, it is another way to show the vpid but is it enough ? I mean if
there are multiple pid namespaces, you will see the vpid '2' or whatever
several times in different /proc/<pid>/status, you will need extra
information to group these processes to belong to a specific pid
namespace, no ?
I am also worried about the 'status' file format and if it is allowed to
add a line in it ... dunno ...
The solution I was proposing is quite similar to this patch, it is just
the 'task_state' function which is modified to show the pid number
relatively to the pid namespace which is looking at the file.
If we are the parent pid namespace, we can look at
/proc/<pid>/root/proc/<vpids>
* we have the list of the processes with the vpids which are the
<vpid> filename
* as we are the parent pid namespace, we look at
/proc/<pid>/root/proc/<vpid>/status and the pids number are the real pids.
* if we are in the child pid namespace, we will see the vpid.
It is similar to the /cgroup/tasks file where the pid numbers are
different depending on what pid namespace we are looking from.
By this way, we don't change the status file format, we have the list of
the processes belonging to a pid namespace with <vpid> and <pid> and we
support nested pid namespaces.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
