[Resend][PATCH] ns,proc: introduce pid_in_ns

[Resend][PATCH] ns,proc: introduce pid_in_ns

[Chen Hanxiao]

We lacked of convenient method of getting the pid inside containers.

If some issues occurred inside container guest, host user
could not know which process is in trouble just by guest pid:
the users of container guest only knew the pid inside containers.
This will bring obstacle for trouble shooting.

This patch introduces pid_in_ns:
If one process is in init_pid_ns, /proc/PID/pid_in_ns
equals to /proc/PID;
if one process is in pidns, /proc/PID/pid_in_ns
will tell the pid inside containers;
if pidns is nested, it depends on which pidns are you in.

Signed-off-by: Chen Hanxiao <chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
 fs/proc/array.c    | 13 +++++++++++++
 fs/proc/base.c     |  1 +
 fs/proc/internal.h |  2 ++
 3 files changed, 16 insertions(+)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 64db2bc..3ff7050 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -562,6 +562,19 @@ int proc_tgid_stat(struct seq_file *m, struct pid_namespace *ns,
 	return do_task_stat(m, ns, pid, task, 1);
 }
 
+int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
+			struct pid *pid, struct task_struct *task)
+{
+	pid_t pid_in_ns;
+	unsigned int level;
+
+	level = pid->level;
+	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
+	seq_put_decimal_ull(m, 0, pid_in_ns);
+	seq_putc(m, '\n');
+	return 0;
+}
+
 int proc_pid_statm(struct seq_file *m, struct pid_namespace *ns,
 			struct pid *pid, struct task_struct *task)
 {
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2d696b0..42904b7 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2574,6 +2574,7 @@ static const struct pid_entry tgid_base_stuff[] = {
 	INF("cmdline",    S_IRUGO, proc_pid_cmdline),
 	ONE("stat",       S_IRUGO, proc_tgid_stat),
 	ONE("statm",      S_IRUGO, proc_pid_statm),
+	ONE("pid_in_ns",  S_IRUGO, proc_pid_in_ns),
 	REG("maps",       S_IRUGO, proc_pid_maps_operations),
 #ifdef CONFIG_NUMA
 	REG("numa_maps",  S_IRUGO, proc_pid_numa_maps_operations),
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 3ab6d14..573841a 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -155,6 +155,8 @@ extern int proc_pid_status(struct seq_file *, struct pid_namespace *,
 			   struct pid *, struct task_struct *);
 extern int proc_pid_statm(struct seq_file *, struct pid_namespace *,
 			  struct pid *, struct task_struct *);
+extern int proc_pid_in_ns(struct seq_file *, struct pid_namespace *,
+			  struct pid *, struct task_struct *);
 
 /*
  * base.c
-- 
1.9.0

[Resend][PATCH] ns,proc: introduce pid_in_ns

[Chen Hanxiao]

We lacked of convenient method of getting the pid inside containers.

If some issues occurred inside container guest, host user
could not know which process is in trouble just by guest pid:
the users of container guest only knew the pid inside containers.
This will bring obstacle for trouble shooting.

This patch introduces pid_in_ns:
If one process is in init_pid_ns, /proc/PID/pid_in_ns
equals to /proc/PID;
if one process is in pidns, /proc/PID/pid_in_ns
will tell the pid inside containers;
if pidns is nested, it depends on which pidns are you in.

Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
---
 fs/proc/array.c    | 13 +++++++++++++
 fs/proc/base.c     |  1 +
 fs/proc/internal.h |  2 ++
 3 files changed, 16 insertions(+)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 64db2bc..3ff7050 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -562,6 +562,19 @@ int proc_tgid_stat(struct seq_file *m, struct pid_namespace *ns,
 	return do_task_stat(m, ns, pid, task, 1);
 }
 
+int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
+			struct pid *pid, struct task_struct *task)
+{
+	pid_t pid_in_ns;
+	unsigned int level;
+
+	level = pid->level;
+	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
+	seq_put_decimal_ull(m, 0, pid_in_ns);
+	seq_putc(m, '\n');
+	return 0;
+}
+
 int proc_pid_statm(struct seq_file *m, struct pid_namespace *ns,
 			struct pid *pid, struct task_struct *task)
 {
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2d696b0..42904b7 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2574,6 +2574,7 @@ static const struct pid_entry tgid_base_stuff[] = {
 	INF("cmdline",    S_IRUGO, proc_pid_cmdline),
 	ONE("stat",       S_IRUGO, proc_tgid_stat),
 	ONE("statm",      S_IRUGO, proc_pid_statm),
+	ONE("pid_in_ns",  S_IRUGO, proc_pid_in_ns),
 	REG("maps",       S_IRUGO, proc_pid_maps_operations),
 #ifdef CONFIG_NUMA
 	REG("numa_maps",  S_IRUGO, proc_pid_numa_maps_operations),
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 3ab6d14..573841a 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -155,6 +155,8 @@ extern int proc_pid_status(struct seq_file *, struct pid_namespace *,
 			   struct pid *, struct task_struct *);
 extern int proc_pid_statm(struct seq_file *, struct pid_namespace *,
 			  struct pid *, struct task_struct *);
+extern int proc_pid_in_ns(struct seq_file *, struct pid_namespace *,
+			  struct pid *, struct task_struct *);
 
 /*
  * base.c
-- 
1.9.0

Re: [Resend][PATCH] ns,proc: introduce pid_in_ns

[Oleg Nesterov]

On 04/25, Chen Hanxiao wrote:
>
> We lacked of convenient method of getting the pid inside containers.
>
> If some issues occurred inside container guest, host user
> could not know which process is in trouble just by guest pid:
> the users of container guest only knew the pid inside containers.
> This will bring obstacle for trouble shooting.
>
> This patch introduces pid_in_ns:
> If one process is in init_pid_ns, /proc/PID/pid_in_ns
> equals to /proc/PID;
> if one process is in pidns, /proc/PID/pid_in_ns
> will tell the pid inside containers;
> if pidns is nested, it depends on which pidns are you in.

Yes another /proc/pid/ file...

Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
list of pid_nr's, from its namespace up to the observer's namespace. The same
for "Tgid:".

(Hmm. And why "Ngid:" was inserted between tid and tgid ?)

> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
> +			struct pid *pid, struct task_struct *task)
> +{
> +	pid_t pid_in_ns;
> +	unsigned int level;
> +
> +	level = pid->level;
> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);

This looks overcomplicated or I missed something?

Oleg.

Re: [Resend][PATCH] ns,proc: introduce pid_in_ns

[Oleg Nesterov]

On 04/25, Chen Hanxiao wrote:
>
> We lacked of convenient method of getting the pid inside containers.
>
> If some issues occurred inside container guest, host user
> could not know which process is in trouble just by guest pid:
> the users of container guest only knew the pid inside containers.
> This will bring obstacle for trouble shooting.
>
> This patch introduces pid_in_ns:
> If one process is in init_pid_ns, /proc/PID/pid_in_ns
> equals to /proc/PID;
> if one process is in pidns, /proc/PID/pid_in_ns
> will tell the pid inside containers;
> if pidns is nested, it depends on which pidns are you in.

Yes another /proc/pid/ file...

Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
list of pid_nr's, from its namespace up to the observer's namespace. The same
for "Tgid:".

(Hmm. And why "Ngid:" was inserted between tid and tgid ?)

> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
> +			struct pid *pid, struct task_struct *task)
> +{
> +	pid_t pid_in_ns;
> +	unsigned int level;
> +
> +	level = pid->level;
> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);

This looks overcomplicated or I missed something?

Oleg.

Re: [Resend][PATCH] ns,proc: introduce pid_in_ns

[Eric W. Biederman]

Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

> On 04/25, Chen Hanxiao wrote:
>>
>> We lacked of convenient method of getting the pid inside containers.

Are unix domain sockets not convinient?

>> If some issues occurred inside container guest, host user
>> could not know which process is in trouble just by guest pid:
>> the users of container guest only knew the pid inside containers.
>> This will bring obstacle for trouble shooting.
>>
>> This patch introduces pid_in_ns:
>> If one process is in init_pid_ns, /proc/PID/pid_in_ns
>> equals to /proc/PID;
>> if one process is in pidns, /proc/PID/pid_in_ns
>> will tell the pid inside containers;
>> if pidns is nested, it depends on which pidns are you in.
>
> Yes another /proc/pid/ file...
>
> Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
> list of pid_nr's, from its namespace up to the observer's namespace. The same
> for "Tgid:".
>
> (Hmm. And why "Ngid:" was inserted between tid and tgid ?)

Add to that Ngid has a completely hosed implementation.  It is a pid
stored in a pid_t, not a struct pid *.  Sigh.

I am getting more and more tempted to obliterate task->pid.  It just
encourages bad code.

>> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
>> +			struct pid *pid, struct task_struct *task)
>> +{
>> +	pid_t pid_in_ns;
>> +	unsigned int level;
>> +
>> +	level = pid->level;
>> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
>
> This looks overcomplicated or I missed something?

I do think if we care we need to print the entire set of pids.
I don't know if /proc/pid/status is the proper place but ...

Eric

Re: [Resend][PATCH] ns,proc: introduce pid_in_ns

[Eric W. Biederman]

Oleg Nesterov <oleg@redhat.com> writes:

> On 04/25, Chen Hanxiao wrote:
>>
>> We lacked of convenient method of getting the pid inside containers.

Are unix domain sockets not convinient?

>> If some issues occurred inside container guest, host user
>> could not know which process is in trouble just by guest pid:
>> the users of container guest only knew the pid inside containers.
>> This will bring obstacle for trouble shooting.
>>
>> This patch introduces pid_in_ns:
>> If one process is in init_pid_ns, /proc/PID/pid_in_ns
>> equals to /proc/PID;
>> if one process is in pidns, /proc/PID/pid_in_ns
>> will tell the pid inside containers;
>> if pidns is nested, it depends on which pidns are you in.
>
> Yes another /proc/pid/ file...
>
> Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
> list of pid_nr's, from its namespace up to the observer's namespace. The same
> for "Tgid:".
>
> (Hmm. And why "Ngid:" was inserted between tid and tgid ?)

Add to that Ngid has a completely hosed implementation.  It is a pid
stored in a pid_t, not a struct pid *.  Sigh.

I am getting more and more tempted to obliterate task->pid.  It just
encourages bad code.

>> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
>> +			struct pid *pid, struct task_struct *task)
>> +{
>> +	pid_t pid_in_ns;
>> +	unsigned int level;
>> +
>> +	level = pid->level;
>> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
>
> This looks overcomplicated or I missed something?

I do think if we care we need to print the entire set of pids.
I don't know if /proc/pid/status is the proper place but ...

Eric

RE: [Resend][PATCH] ns,proc: introduce pid_in_ns

[chenhanxiao-BthXqXjhjHXQFUHtdCDX3A]

> -----Original Message-----
> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> Sent: Saturday, April 26, 2014 3:18 AM
> To: Oleg Nesterov
> Cc: Chen, Hanxiao/陈 晗霄; containers@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org; Andrew Morton; Serge Hallyn; Daniel P. Berrange;
> Al Viro; David Howells
> Subject: Re: [Resend][PATCH] ns,proc: introduce pid_in_ns
> 
> Oleg Nesterov <oleg@redhat.com> writes:
> 
> > On 04/25, Chen Hanxiao wrote:
> >>
> >> We lacked of convenient method of getting the pid inside containers.
> 
> Are unix domain sockets not convinient?
> 

It's a very good method, but not so directly for just pid translation.

> >> If some issues occurred inside container guest, host user
> >> could not know which process is in trouble just by guest pid:
> >> the users of container guest only knew the pid inside containers.
> >> This will bring obstacle for trouble shooting.
> >>
> >> This patch introduces pid_in_ns:
> >> If one process is in init_pid_ns, /proc/PID/pid_in_ns
> >> equals to /proc/PID;
> >> if one process is in pidns, /proc/PID/pid_in_ns
> >> will tell the pid inside containers;
> >> if pidns is nested, it depends on which pidns are you in.
> >
> > Yes another /proc/pid/ file...
> >
> > Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
> > list of pid_nr's, from its namespace up to the observer's namespace. The same
> > for "Tgid:".
> >
> > (Hmm. And why "Ngid:" was inserted between tid and tgid ?)
> 
> Add to that Ngid has a completely hosed implementation.  It is a pid
> stored in a pid_t, not a struct pid *.  Sigh.
> 
> I am getting more and more tempted to obliterate task->pid.  It just
> encourages bad code.
> 
> >> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
> >> +			struct pid *pid, struct task_struct *task)
> >> +{
> >> +	pid_t pid_in_ns;
> >> +	unsigned int level;
> >> +
> >> +	level = pid->level;
> >> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
> >
> > This looks overcomplicated or I missed something?
> 
> I do think if we care we need to print the entire set of pids.
> I don't know if /proc/pid/status is the proper place but ...
> 

Let's print the entire set of pids in /proc/pid/status.

> Eric

Thanks for the comments.
v2 will come soon.

- Chen

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

RE: [Resend][PATCH] ns,proc: introduce pid_in_ns

[chenhanxiao]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 2467 bytes --]



> -----Original Message-----
> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> Sent: Saturday, April 26, 2014 3:18 AM
> To: Oleg Nesterov
> Cc: Chen, Hanxiao/³Â êÏÏö; containers@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org; Andrew Morton; Serge Hallyn; Daniel P. Berrange;
> Al Viro; David Howells
> Subject: Re: [Resend][PATCH] ns,proc: introduce pid_in_ns
> 
> Oleg Nesterov <oleg@redhat.com> writes:
> 
> > On 04/25, Chen Hanxiao wrote:
> >>
> >> We lacked of convenient method of getting the pid inside containers.
> 
> Are unix domain sockets not convinient?
> 

It's a very good method, but not so directly for just pid translation.

> >> If some issues occurred inside container guest, host user
> >> could not know which process is in trouble just by guest pid:
> >> the users of container guest only knew the pid inside containers.
> >> This will bring obstacle for trouble shooting.
> >>
> >> This patch introduces pid_in_ns:
> >> If one process is in init_pid_ns, /proc/PID/pid_in_ns
> >> equals to /proc/PID;
> >> if one process is in pidns, /proc/PID/pid_in_ns
> >> will tell the pid inside containers;
> >> if pidns is nested, it depends on which pidns are you in.
> >
> > Yes another /proc/pid/ file...
> >
> > Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
> > list of pid_nr's, from its namespace up to the observer's namespace. The same
> > for "Tgid:".
> >
> > (Hmm. And why "Ngid:" was inserted between tid and tgid ?)
> 
> Add to that Ngid has a completely hosed implementation.  It is a pid
> stored in a pid_t, not a struct pid *.  Sigh.
> 
> I am getting more and more tempted to obliterate task->pid.  It just
> encourages bad code.
> 
> >> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
> >> +			struct pid *pid, struct task_struct *task)
> >> +{
> >> +	pid_t pid_in_ns;
> >> +	unsigned int level;
> >> +
> >> +	level = pid->level;
> >> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
> >
> > This looks overcomplicated or I missed something?
> 
> I do think if we care we need to print the entire set of pids.
> I don't know if /proc/pid/status is the proper place but ...
> 

Let's print the entire set of pids in /proc/pid/status.

> Eric

Thanks for the comments.
v2 will come soon.

- Chen

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥