[PATCH v2] ns: introduce getnspid syscall

[PATCH v2] ns: introduce getnspid syscall

[Chen Hanxiao]

We need a direct 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.

int getnspid(pid_t pid, int fd1, int fd2);

pid: the pid number need to be translated.

fd: a file descriptor referring to one of
    the namespace entries in a /proc/[pid]/ns/pid.
    fd1 for destination ns(ns1), where the pid came from.
    fd2 for reference ns(ns2), while fd2 = -2 means for current ns.

return value:
    >0 : translated pid in ns1(fd1) seen from ns2(fd2).
    <=0: on failure.

Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
---
v2: drop pidtype
    check ns_ops before getting pid_namespace structure

 arch/x86/syscalls/syscall_32.tbl |  1 +
 arch/x86/syscalls/syscall_64.tbl |  1 +
 include/linux/syscalls.h         |  1 +
 kernel/nsproxy.c                 | 45 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 48 insertions(+)

diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index d6b8679..9de0b32 100644
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@ -360,3 +360,4 @@
 351	i386	sched_setattr		sys_sched_setattr
 352	i386	sched_getattr		sys_sched_getattr
 353	i386	renameat2		sys_renameat2
+354	i386	getnspid		sys_getnspid
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index ec255a1..1630a8a 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -323,6 +323,7 @@
 314	common	sched_setattr		sys_sched_setattr
 315	common	sched_getattr		sys_sched_getattr
 316	common	renameat2		sys_renameat2
+317	common	getnspid		sys_getnspid
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index b0881a0..53dd0e8 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -866,4 +866,5 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
 asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
 			 unsigned long idx1, unsigned long idx2);
 asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags);
+asmlinkage long sys_getpidns(pid_t pid, int fd1, int fd2);
 #endif
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 8e78110..9701ade 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -261,6 +261,51 @@ out:
 	return err;
 }
 
+SYSCALL_DEFINE3(getnspid, pid_t, pid, int, fd1, int, fd2)
+{
+	struct file *file1 = NULL, *file2 = NULL;
+	struct pid *pid_struct;
+	struct pid_namespace *ns1, *ns2;
+	struct proc_ns *ei;
+	int ret = -EINVAL;
+
+	file1 = proc_ns_fget(fd1);
+	if (IS_ERR(file1))
+		return PTR_ERR(file1);
+	ei = get_proc_ns(file_inode(file1));
+	if (ei->ns_ops != &pidns_operations)
+		goto out;
+	ns1 = (struct pid_namespace *)ei->ns;
+
+	/* fd == -2 for current pid ns */
+	if (fd2 == -2) {
+		ns2 = task_active_pid_ns(current);
+	} else {
+		file2 = proc_ns_fget(fd2);
+		if (IS_ERR(file2)) {
+			fput(file1);
+			return PTR_ERR(file2);
+		}
+		ei = get_proc_ns(file_inode(file2));
+		if (ei->ns_ops != &pidns_operations)
+			goto out;
+		ns2 = (struct pid_namespace *)ei->ns;
+	}
+
+	pid_struct = find_pid_ns(pid, ns1);
+	if (!pid_struct) {
+		ret = -ESRCH;
+		goto out;
+	}
+
+	ret = pid_nr_ns(pid_struct, ns2);
+out:
+	fput(file1);
+	if (file2)
+		fput(file2);
+	return ret;
+}
+
 int __init nsproxy_cache_init(void)
 {
 	nsproxy_cachep = KMEM_CACHE(nsproxy, SLAB_PANIC);
-- 
1.9.0

Re: [PATCH v2] ns: introduce getnspid syscall

[Richard Weinberger]

Am 20.06.2014 12:18, schrieb Chen Hanxiao:
> We need a direct 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.
> 
> int getnspid(pid_t pid, int fd1, int fd2);
> 
> pid: the pid number need to be translated.
> 
> fd: a file descriptor referring to one of
>     the namespace entries in a /proc/[pid]/ns/pid.
>     fd1 for destination ns(ns1), where the pid came from.
>     fd2 for reference ns(ns2), while fd2 = -2 means for current ns.
> 
> return value:
>     >0 : translated pid in ns1(fd1) seen from ns2(fd2).
>     <=0: on failure.
>

I don't think that adding a new system call for this is a good solution.
We need a more generic way. I bet people are interested in more than just PID numbers.

I agree with Eric that a procfs solution is more appropriate.

Thanks,
//richard

> Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
> ---
> v2: drop pidtype
>     check ns_ops before getting pid_namespace structure
> 
>  arch/x86/syscalls/syscall_32.tbl |  1 +
>  arch/x86/syscalls/syscall_64.tbl |  1 +
>  include/linux/syscalls.h         |  1 +
>  kernel/nsproxy.c                 | 45 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 48 insertions(+)
> 
> diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
> index d6b8679..9de0b32 100644
> --- a/arch/x86/syscalls/syscall_32.tbl
> +++ b/arch/x86/syscalls/syscall_32.tbl
> @@ -360,3 +360,4 @@
>  351	i386	sched_setattr		sys_sched_setattr
>  352	i386	sched_getattr		sys_sched_getattr
>  353	i386	renameat2		sys_renameat2
> +354	i386	getnspid		sys_getnspid
> diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
> index ec255a1..1630a8a 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -323,6 +323,7 @@
>  314	common	sched_setattr		sys_sched_setattr
>  315	common	sched_getattr		sys_sched_getattr
>  316	common	renameat2		sys_renameat2
> +317	common	getnspid		sys_getnspid
>  
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index b0881a0..53dd0e8 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -866,4 +866,5 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
>  asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
>  			 unsigned long idx1, unsigned long idx2);
>  asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags);
> +asmlinkage long sys_getpidns(pid_t pid, int fd1, int fd2);
>  #endif
> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> index 8e78110..9701ade 100644
> --- a/kernel/nsproxy.c
> +++ b/kernel/nsproxy.c
> @@ -261,6 +261,51 @@ out:
>  	return err;
>  }
>  
> +SYSCALL_DEFINE3(getnspid, pid_t, pid, int, fd1, int, fd2)
> +{
> +	struct file *file1 = NULL, *file2 = NULL;
> +	struct pid *pid_struct;
> +	struct pid_namespace *ns1, *ns2;
> +	struct proc_ns *ei;
> +	int ret = -EINVAL;
> +
> +	file1 = proc_ns_fget(fd1);
> +	if (IS_ERR(file1))
> +		return PTR_ERR(file1);
> +	ei = get_proc_ns(file_inode(file1));
> +	if (ei->ns_ops != &pidns_operations)
> +		goto out;
> +	ns1 = (struct pid_namespace *)ei->ns;
> +
> +	/* fd == -2 for current pid ns */
> +	if (fd2 == -2) {
> +		ns2 = task_active_pid_ns(current);
> +	} else {
> +		file2 = proc_ns_fget(fd2);
> +		if (IS_ERR(file2)) {
> +			fput(file1);
> +			return PTR_ERR(file2);
> +		}
> +		ei = get_proc_ns(file_inode(file2));
> +		if (ei->ns_ops != &pidns_operations)
> +			goto out;
> +		ns2 = (struct pid_namespace *)ei->ns;
> +	}
> +
> +	pid_struct = find_pid_ns(pid, ns1);
> +	if (!pid_struct) {
> +		ret = -ESRCH;
> +		goto out;
> +	}
> +
> +	ret = pid_nr_ns(pid_struct, ns2);
> +out:
> +	fput(file1);
> +	if (file2)
> +		fput(file2);
> +	return ret;
> +}
> +
>  int __init nsproxy_cache_init(void)
>  {
>  	nsproxy_cachep = KMEM_CACHE(nsproxy, SLAB_PANIC);
> 

RE: [PATCH v2] ns: introduce getnspid syscall

[chenhanxiao]

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

Hi

> -----Original Message-----
> From: Richard Weinberger [mailto:richard@nod.at]
> Sent: Friday, June 20, 2014 7:02 PM
> To: Chen, Hanxiao/³Â êÏÏö; containers@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org
> Cc: Eric W. Biederman; Serge Hallyn; Daniel P. Berrange; Oleg Nesterov; Al Viro;
> David Howells; Pavel Emelyanov; Vasiliy Kulikov; Gotou, Yasunori/Îåu ¿µÎÄ;
> linux-api@vger.kernel.org
> Subject: Re: [PATCH v2] ns: introduce getnspid syscall
> 
> Am 20.06.2014 12:18, schrieb Chen Hanxiao:
> > We need a direct 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.
> >
> > int getnspid(pid_t pid, int fd1, int fd2);
> >
> > pid: the pid number need to be translated.
> >
> > fd: a file descriptor referring to one of
> >     the namespace entries in a /proc/[pid]/ns/pid.
> >     fd1 for destination ns(ns1), where the pid came from.
> >     fd2 for reference ns(ns2), while fd2 = -2 means for current ns.
> >
> > return value:
> >     >0 : translated pid in ns1(fd1) seen from ns2(fd2).
> >     <=0: on failure.
> >
> 
> I don't think that adding a new system call for this is a good solution.
> We need a more generic way. I bet people are interested in more than just PID
> numbers.

Could you please give some hints on how to expand this interface?

> 
> I agree with Eric that a procfs solution is more appropriate.
> 

Procfs is a good solution, but syscall is not bad though.
Procfs works for me, but that seems could not fit
Pavel's requirement.
His opinion is that a syscall is a more generic interface
than proc files, and  also very helpful.
And syscall could tell whether a pid lives in a specific pid namespace,
much convenient than procfs.

Thanks,
- 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¥

Re: [PATCH v2] ns: introduce getnspid syscall

[Serge E. Hallyn]

Quoting chenhanxiao@cn.fujitsu.com (chenhanxiao@cn.fujitsu.com):
> Hi
> 
> > -----Original Message-----
> > From: Richard Weinberger [mailto:richard@nod.at]
> > Sent: Friday, June 20, 2014 7:02 PM
> > To: Chen, Hanxiao/陈 晗霄; containers@lists.linux-foundation.org;
> > linux-kernel@vger.kernel.org
> > Cc: Eric W. Biederman; Serge Hallyn; Daniel P. Berrange; Oleg Nesterov; Al Viro;
> > David Howells; Pavel Emelyanov; Vasiliy Kulikov; Gotou, Yasunori/五島 康文;
> > linux-api@vger.kernel.org
> > Subject: Re: [PATCH v2] ns: introduce getnspid syscall
> > 
> > Am 20.06.2014 12:18, schrieb Chen Hanxiao:
> > > We need a direct 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.
> > >
> > > int getnspid(pid_t pid, int fd1, int fd2);
> > >
> > > pid: the pid number need to be translated.
> > >
> > > fd: a file descriptor referring to one of
> > >     the namespace entries in a /proc/[pid]/ns/pid.
> > >     fd1 for destination ns(ns1), where the pid came from.
> > >     fd2 for reference ns(ns2), while fd2 = -2 means for current ns.
> > >
> > > return value:
> > >     >0 : translated pid in ns1(fd1) seen from ns2(fd2).
> > >     <=0: on failure.
> > >
> > 
> > I don't think that adding a new system call for this is a good solution.
> > We need a more generic way. I bet people are interested in more than just PID
> > numbers.
> 
> Could you please give some hints on how to expand this interface?
> 
> > 
> > I agree with Eric that a procfs solution is more appropriate.
> > 
> 
> Procfs is a good solution, but syscall is not bad though.

I might be inclined to agree, except that in this case you are still
needing mounted procfs anyway to get the proc/$pid/ns/pid fds.

I'm sorry, I've not been watching this thread, so this probably has been
considered and decided against, but I'm going to ask anyway.  Keeping
in mind both checkpoint-restart and and introspection for use in a
setns'd commend, why not make it

pid_t getnspid(pid_t query_pid, pid_t observer_pid)

which returns the process id of query_pid as seen from observer_pid's
pidns?


> Procfs works for me, but that seems could not fit
> Pavel's requirement.
> His opinion is that a syscall is a more generic interface
> than proc files, and  also very helpful.
> And syscall could tell whether a pid lives in a specific pid namespace,
> much convenient than procfs.
> 
> Thanks,
> - Chen

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

RE: [PATCH v2] ns: introduce getnspid syscall

[chenhanxiao]

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

Hi,

> -----Original Message-----
> From: Serge E. Hallyn [mailto:serge@hallyn.com]
> Sent: Monday, June 23, 2014 9:33 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: Richard Weinberger; containers@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org; Pavel Emelyanov; linux-api@vger.kernel.org;
> Serge Hallyn; Oleg Nesterov; David Howells; Eric W. Biederman; Al Viro
> Subject: Re: [PATCH v2] ns: introduce getnspid syscall
> 
> > > >
> > >
> > > I don't think that adding a new system call for this is a good solution.
> > > We need a more generic way. I bet people are interested in more than just
> PID
> > > numbers.
> >
> > Could you please give some hints on how to expand this interface?
> >
> > >
> > > I agree with Eric that a procfs solution is more appropriate.
> > >
> >
> > Procfs is a good solution, but syscall is not bad though.
> 
> I might be inclined to agree, except that in this case you are still
> needing mounted procfs anyway to get the proc/$pid/ns/pid fds.
> 
> I'm sorry, I've not been watching this thread, so this probably has been
> considered and decided against, but I'm going to ask anyway.  Keeping
> in mind both checkpoint-restart and and introspection for use in a
> setns'd commend, why not make it
> 
> pid_t getnspid(pid_t query_pid, pid_t observer_pid)
> 
> which returns the process id of query_pid as seen from observer_pid's
> pidns?
> 

But this could be confused in nested ns.

Ex:
(thanks for Pavel's figure)
    init_pid_ns    ns1         ns2
t1  2
t2   `- 3          1 
t3       `- 4      `- 5        1
t4  5

a) getnspid(1, 1):
We expected it could return t2's pid(2nd 1 as pid
such as systemd in init_pid_ns),
but t3'pid is also an appropriate result.
We may get more than one returns.

b) getnspid(5, 1):
(1st 5 was expected as  pid in ns1)
t3'pid and t4's pid could both be the answer.
We could not determine which one is what we want.

So something unique like fds of ns should be
a better reference. 

Thanks,
- Chen

> 
> > Procfs works for me, but that seems could not fit
> > Pavel's requirement.
> > His opinion is that a syscall is a more generic interface
> > than proc files, and  also very helpful.
> > And syscall could tell whether a pid lives in a specific pid namespace,
> > much convenient than procfs.
> >
> > Thanks,
> > - Chen
> 
> > _______________________________________________
> > Containers mailing list
> > Containers@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers

ÿôèº{.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¥

Re: [PATCH v2] ns: introduce getnspid syscall

[Serge Hallyn]

Quoting chenhanxiao@cn.fujitsu.com (chenhanxiao@cn.fujitsu.com):
> Hi,
> 
> > -----Original Message-----
> > From: Serge E. Hallyn [mailto:serge@hallyn.com]
> > Sent: Monday, June 23, 2014 9:33 PM
> > To: Chen, Hanxiao/陈 晗霄
> > Cc: Richard Weinberger; containers@lists.linux-foundation.org;
> > linux-kernel@vger.kernel.org; Pavel Emelyanov; linux-api@vger.kernel.org;
> > Serge Hallyn; Oleg Nesterov; David Howells; Eric W. Biederman; Al Viro
> > Subject: Re: [PATCH v2] ns: introduce getnspid syscall
> > 
> > > > >
> > > >
> > > > I don't think that adding a new system call for this is a good solution.
> > > > We need a more generic way. I bet people are interested in more than just
> > PID
> > > > numbers.
> > >
> > > Could you please give some hints on how to expand this interface?
> > >
> > > >
> > > > I agree with Eric that a procfs solution is more appropriate.
> > > >
> > >
> > > Procfs is a good solution, but syscall is not bad though.
> > 
> > I might be inclined to agree, except that in this case you are still
> > needing mounted procfs anyway to get the proc/$pid/ns/pid fds.
> > 
> > I'm sorry, I've not been watching this thread, so this probably has been
> > considered and decided against, but I'm going to ask anyway.  Keeping
> > in mind both checkpoint-restart and and introspection for use in a
> > setns'd commend, why not make it
> > 
> > pid_t getnspid(pid_t query_pid, pid_t observer_pid)
> > 
> > which returns the process id of query_pid as seen from observer_pid's
> > pidns?
> > 
> 
> But this could be confused in nested ns.
> 
> Ex:
> (thanks for Pavel's figure)
>     init_pid_ns    ns1         ns2
> t1  2
> t2   `- 3          1 
> t3       `- 4      `- 5        1
> t4  5
> 
> a) getnspid(1, 1):
> We expected it could return t2's pid(2nd 1 as pid

Clearly the passed-in pids should be interpreted as relative
to current's pidns.  There can be no ambiguity at that point,
unless I'm overlooking something.

> such as systemd in init_pid_ns),
> but t3'pid is also an appropriate result.
> We may get more than one returns.
> 
> b) getnspid(5, 1):
> (1st 5 was expected as  pid in ns1)
> t3'pid and t4's pid could both be the answer.
> We could not determine which one is what we want.
> 
> So something unique like fds of ns should be
> a better reference. 
> 
> Thanks,
> - Chen
> 
> > 
> > > Procfs works for me, but that seems could not fit
> > > Pavel's requirement.
> > > His opinion is that a syscall is a more generic interface
> > > than proc files, and  also very helpful.
> > > And syscall could tell whether a pid lives in a specific pid namespace,
> > > much convenient than procfs.
> > >
> > > Thanks,
> > > - Chen
> > 
> > > _______________________________________________
> > > Containers mailing list
> > > Containers@lists.linux-foundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/containers
> 
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

RE: [PATCH v2] ns: introduce getnspid syscall

[chenhanxiao]

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



> -----Original Message-----
> From: Serge Hallyn [mailto:serge.hallyn@ubuntu.com]
> Sent: Wednesday, June 25, 2014 10:39 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: Serge E. Hallyn; Eric W. Biederman; Richard Weinberger;
> containers@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Oleg
> Nesterov; David Howells; Al Viro; linux-api@vger.kernel.org
> > > > > >
> > > > >
> > > > > I don't think that adding a new system call for this is a good solution.
> > > > > We need a more generic way. I bet people are interested in more than just
> > > PID
> > > > > numbers.
> > > >
> > > > Could you please give some hints on how to expand this interface?
> > > >
> > > > >
> > > > > I agree with Eric that a procfs solution is more appropriate.
> > > > >
> > > >
> > > > Procfs is a good solution, but syscall is not bad though.
> > >
> > > I might be inclined to agree, except that in this case you are still
> > > needing mounted procfs anyway to get the proc/$pid/ns/pid fds.
> > >
> > > I'm sorry, I've not been watching this thread, so this probably has been
> > > considered and decided against, but I'm going to ask anyway.  Keeping
> > > in mind both checkpoint-restart and and introspection for use in a
> > > setns'd commend, why not make it
> > >
> > > pid_t getnspid(pid_t query_pid, pid_t observer_pid)
> > >
> > > which returns the process id of query_pid as seen from observer_pid's
> > > pidns?
> > >
> >
> > But this could be confused in nested ns.
> >
> > Ex:
> > (thanks for Pavel's figure)
> >     init_pid_ns    ns1         ns2
> > t1  2
> > t2   `- 3          1
> > t3       `- 4      `- 5        1
> > t4  5
> >
> > a) getnspid(1, 1):
> > We expected it could return t2's pid(2nd 1 as pid
> 
> Clearly the passed-in pids should be interpreted as relative
> to current's pidns.  There can be no ambiguity at that point,
> unless I'm overlooking something.
> 

Default to current's pidns looks reasonable.
But nested namespace will still bring trouble to us.
Since the middle level of namespace looks less attractive to users,
how about ignore them, and just show the deepest level's pid?

Ex:
(Thanks for Pavel's figure again)
    init_pid_ns    ns1         ns2
t1  2
t2   `- 3          1
t3       `- 4      `- 5        1
t4           `- 5       `-7      `- 2

1. In init_pid_ns:
a) getnspid(2, 1):
returns 2 (t1)

b) getnspid(1, 3):
returns 3 (t2)

c) getnspid(1, 4):
returns 4 (t3)

getnspid(2, 4):
returns 5 (t3)

2. In ns1
a) getnspid(2, 5):
returns 7 (t4)

How do you like this idea?

Thanks,
- Chen

> > such as systemd in init_pid_ns),
> > but t3'pid is also an appropriate result.
> > We may get more than one returns.
> >
> > b) getnspid(5, 1):
> > (1st 5 was expected as  pid in ns1)
> > t3'pid and t4's pid could both be the answer.
> > We could not determine which one is what we want.
> >
> > So something unique like fds of ns should be
> > a better reference.
> >
> > Thanks,
> > - Chen
> >
> > >
> > > > Procfs works for me, but that seems could not fit
> > > > Pavel's requirement.
> > > > His opinion is that a syscall is a more generic interface
> > > > than proc files, and  also very helpful.
> > > > And syscall could tell whether a pid lives in a specific pid namespace,
> > > > much convenient than procfs.
> > > >
> > > > Thanks,
> > > > - Chen
> > >
> > > > _______________________________________________
> > > > Containers mailing list
> > > > Containers@lists.linux-foundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/containers
> >
> > _______________________________________________
> > Containers mailing list
> > Containers@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers
ÿôèº{.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¥