From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932349AbbIYNw4 (ORCPT <rfc822;w@1wt.eu>);
	Fri, 25 Sep 2015 09:52:56 -0400
Received: from forward-corp1f.mail.yandex.net ([95.108.130.40]:45084 "EHLO
	forward-corp1f.mail.yandex.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S932206AbbIYNwy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Sep 2015 09:52:54 -0400
Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru
Subject: [PATCH RFC v3 1/2] nsfs: replace proc_ns_fget() with proc_ns_fdget()
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
To: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org
Cc: Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?b?U3TDqXBoYW5l?= Graber <stgraber@ubuntu.com>
Date: Fri, 25 Sep 2015 16:52:46 +0300
Message-ID: <20150925135246.27620.97496.stgit@buzz>
User-Agent: StGit/0.17.1-dirty
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

New helper function returns pointer to struct ns_common, can check
namespace type and uses struct fd for returning file reference:
this saves couple atomic operations for single-threaded applications.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 fs/nsfs.c                |   20 +++++++++++++-------
 include/linux/proc_ns.h  |    4 +++-
 kernel/nsproxy.c         |   15 +++++----------
 net/core/net_namespace.c |   18 ++++++------------
 4 files changed, 27 insertions(+), 30 deletions(-)

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 8f20d6016e20..a2e803c97960 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -119,21 +119,27 @@ int ns_get_name(char *buf, size_t size, struct task_struct *task,
 	return res;
 }
 
-struct file *proc_ns_fget(int fd)
+struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
 {
-	struct file *file;
+	struct ns_common *ns;
+	struct fd f;
 
-	file = fget(fd);
-	if (!file)
+	f = fdget(fd);
+	if (!f.file)
 		return ERR_PTR(-EBADF);
 
-	if (file->f_op != &ns_file_operations)
+	if (f.file->f_op != &ns_file_operations)
+		goto out_invalid;
+
+	ns = get_proc_ns(file_inode(f.file));
+	if (nstype && (ns->ops->type != nstype))
 		goto out_invalid;
 
-	return file;
+	*fd_ref = f;
+	return ns;
 
 out_invalid:
-	fput(file);
+	fdput(f);
 	return ERR_PTR(-EINVAL);
 }
 
diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h
index 42dfc615dbf8..406ea4617606 100644
--- a/include/linux/proc_ns.h
+++ b/include/linux/proc_ns.h
@@ -9,6 +9,7 @@
 struct pid_namespace;
 struct nsproxy;
 struct path;
+struct fd;
 
 struct proc_ns_operations {
 	const char *name;
@@ -65,7 +66,8 @@ static inline int ns_alloc_inum(struct ns_common *ns)
 
 #define ns_free_inum(ns) proc_free_inum((ns)->inum)
 
-extern struct file *proc_ns_fget(int fd);
+extern struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref);
+
 #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
 extern void *ns_get_path(struct path *path, struct task_struct *task,
 			const struct proc_ns_operations *ns_ops);
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 49746c81ad8d..689b929a0fcb 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -222,18 +222,13 @@ SYSCALL_DEFINE2(setns, int, fd, int, nstype)
 {
 	struct task_struct *tsk = current;
 	struct nsproxy *new_nsproxy;
-	struct file *file;
+	struct fd fd_ref;
 	struct ns_common *ns;
 	int err;
 
-	file = proc_ns_fget(fd);
-	if (IS_ERR(file))
-		return PTR_ERR(file);
-
-	err = -EINVAL;
-	ns = get_proc_ns(file_inode(file));
-	if (nstype && (ns->ops->type != nstype))
-		goto out;
+	ns = proc_ns_fdget(fd, nstype, &fd_ref);
+	if (IS_ERR(ns))
+		return PTR_ERR(ns);
 
 	new_nsproxy = create_new_namespaces(0, tsk, current_user_ns(), tsk->fs);
 	if (IS_ERR(new_nsproxy)) {
@@ -248,7 +243,7 @@ SYSCALL_DEFINE2(setns, int, fd, int, nstype)
 	}
 	switch_task_namespaces(tsk, new_nsproxy);
 out:
-	fput(file);
+	fdput(fd_ref);
 	return err;
 }
 
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 2c2eb1b629b1..ffc5e6df86dc 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -465,21 +465,15 @@ EXPORT_SYMBOL_GPL(__put_net);
 
 struct net *get_net_ns_by_fd(int fd)
 {
-	struct file *file;
 	struct ns_common *ns;
+	struct fd fd_ref;
 	struct net *net;
 
-	file = proc_ns_fget(fd);
-	if (IS_ERR(file))
-		return ERR_CAST(file);
-
-	ns = get_proc_ns(file_inode(file));
-	if (ns->ops == &netns_operations)
-		net = get_net(container_of(ns, struct net, ns));
-	else
-		net = ERR_PTR(-EINVAL);
-
-	fput(file);
+	ns = proc_ns_fdget(fd, CLONE_NEWNET, &fd_ref);
+	if (IS_ERR(ns))
+		return ERR_CAST(ns);
+	net = get_net(container_of(ns, struct net, ns));
+	fdput(fd_ref);
 	return net;
 }
 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932372AbbIYNw7 (ORCPT <rfc822;w@1wt.eu>);
	Fri, 25 Sep 2015 09:52:59 -0400
Received: from forward-corp1f.mail.yandex.net ([95.108.130.40]:45097 "EHLO
	forward-corp1f.mail.yandex.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S932260AbbIYNwz (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Sep 2015 09:52:55 -0400
Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru
Subject: [PATCH RFC v3 2/2] pidns: introduce syscall getvpid
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
To: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org
Cc: Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?b?U3TDqXBoYW5l?= Graber <stgraber@ubuntu.com>
Date: Fri, 25 Sep 2015 16:52:47 +0300
Message-ID: <20150925135247.27620.37109.stgit@buzz>
In-Reply-To: <20150925135246.27620.97496.stgit@buzz>
References: <20150925135246.27620.97496.stgit@buzz>
User-Agent: StGit/0.17.1-dirty
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

pid_t getvpid(pid_t pid, int source, int target);

This syscall converts pid from source pid-namespace into pid visible
in target pid-namespace. If pid is unreachable from target namespace
then getvpid() returns zero.

Namespaces are defined by file descriptors pointing to entries in
proc (/proc/[pid]/ns/pid). If argument is negative then current pid
namespace is used.

If pid is negative then getvpid() returns pid of parent task for -pid.

Possible error codes:
ESRCH    - task not found
EBADF    - closed file descriptor
EINVAL   - not pid-namespace file descriptor

Such conversion is required for interaction between processes from
different pid-namespaces. For example system service at host system
who provide access to restricted set of privileged operations for
clients from containers have to convert pids back and forward.

Recent kernels expose virtual pids in /proc/[pid]/status:NSpid, but
this interface works only in one way and even that is non-trivial.

Other option is passing pids with credentials via unix socket, but
this solution requires a lot of preparation and CAP_SYS_ADMIN for
sending arbitrary pids.

This syscall works in both directions, it's fast and simple.

Examples:
getvpid(pid, ns, -1)      - get pid in our pid namespace
getvpid(pid, -1, ns)      - get pid in container
getvpid(pid, -1, ns) > 0  - is pid is reachable from container?
getvpid(1, ns1, ns2) > 0  - is ns1 inside ns2?
getvpid(1, ns1, ns2) == 0 - is ns1 outside ns2?
getvpid(1, ns, -1)        - get init task of pid-namespace
getvpid(-1, ns, -1)       - get reaper of init task in parent pid-namespace
getvpid(-pid, -1, -1)     - get ppid by pid

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>

--

v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml.org/lkml/2015/9/24/278
v3:
 * use proc_ns_fdget()
 * update description
 * rebase to next-20150925
 * fix conflict with mlock2
---
 arch/x86/entry/syscalls/syscall_32.tbl |    1 +
 arch/x86/entry/syscalls/syscall_64.tbl |    1 +
 include/linux/syscalls.h               |    1 +
 include/uapi/asm-generic/unistd.h      |    4 ++-
 kernel/sys.c                           |   51 ++++++++++++++++++++++++++++++++
 5 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index 143ef9f37932..c36c2c65d204 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -383,3 +383,4 @@
 374	i386	userfaultfd		sys_userfaultfd
 375	i386	membarrier		sys_membarrier
 376	i386	mlock2			sys_mlock2
+377	i386	getvpid			sys_getvpid
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index 314a90bfc09c..90bbbc7fdbe0 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -332,6 +332,7 @@
 323	common	userfaultfd		sys_userfaultfd
 324	common	membarrier		sys_membarrier
 325	common	mlock2			sys_mlock2
+326	common	getvpid			sys_getvpid
 
 #
 # 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 a156b82dd14c..dbb5638260b5 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -222,6 +222,7 @@ asmlinkage long sys_nanosleep(struct timespec __user *rqtp, struct timespec __us
 asmlinkage long sys_alarm(unsigned int seconds);
 asmlinkage long sys_getpid(void);
 asmlinkage long sys_getppid(void);
+asmlinkage long sys_getvpid(pid_t pid, int source, int target);
 asmlinkage long sys_getuid(void);
 asmlinkage long sys_geteuid(void);
 asmlinkage long sys_getgid(void);
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index 1324b0292ec2..2c1123130f90 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -715,9 +715,11 @@ __SYSCALL(__NR_userfaultfd, sys_userfaultfd)
 __SYSCALL(__NR_membarrier, sys_membarrier)
 #define __NR_mlock2 284
 __SYSCALL(__NR_mlock2, sys_mlock2)
+#define __NR_mlock2 285
+__SYSCALL(__NR_getvpid, sys_getvpid)
 
 #undef __NR_syscalls
-#define __NR_syscalls 285
+#define __NR_syscalls 286
 
 /*
  * All syscalls below here should go away really,
diff --git a/kernel/sys.c b/kernel/sys.c
index fa2f2f671a5c..1e28a36b84fa 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -46,6 +46,7 @@
 #include <linux/syscalls.h>
 #include <linux/kprobes.h>
 #include <linux/user_namespace.h>
+#include <linux/proc_ns.h>
 #include <linux/binfmts.h>
 
 #include <linux/sched.h>
@@ -855,6 +856,56 @@ SYSCALL_DEFINE0(getppid)
 	return pid;
 }
 
+SYSCALL_DEFINE3(getvpid, pid_t, pid, int, source, int, target)
+{
+	struct pid_namespace *source_ns, *target_ns;
+	struct fd source_fd = {}, target_fd = {};
+	struct pid *struct_pid;
+	struct ns_common *ns;
+	pid_t result;
+
+	if (source >= 0) {
+		ns = proc_ns_fdget(source, CLONE_NEWPID, &source_fd);
+		result = PTR_ERR(ns);
+		if (IS_ERR(ns))
+			goto out;
+		source_ns = container_of(ns, struct pid_namespace, ns);
+	} else
+		source_ns = task_active_pid_ns(current);
+
+	if (target >= 0) {
+		ns = proc_ns_fdget(target, CLONE_NEWPID, &target_fd);
+		result = PTR_ERR(ns);
+		if (IS_ERR(ns))
+			goto out;
+		target_ns = container_of(ns, struct pid_namespace, ns);
+	} else
+		target_ns = task_active_pid_ns(current);
+
+	rcu_read_lock();
+	struct_pid = find_pid_ns(abs(pid), source_ns);
+
+	if (struct_pid && pid < 0) {
+		struct task_struct *task;
+
+		task = pid_task(struct_pid, PIDTYPE_PID);
+		if (task)
+			task = rcu_dereference(task->real_parent);
+		struct_pid = task ? task_pid(task) : NULL;
+	}
+
+	if (struct_pid)
+		result = pid_nr_ns(struct_pid, target_ns);
+	else
+		result = -ESRCH;
+	rcu_read_unlock();
+
+out:
+	fdput(target_fd);
+	fdput(source_fd);
+	return result;
+}
+
 SYSCALL_DEFINE0(getuid)
 {
 	/* Only we change this so SMP safe */


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933000AbbIYSAF (ORCPT <rfc822;w@1wt.eu>);
	Fri, 25 Sep 2015 14:00:05 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49316 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932907AbbIYR77 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Sep 2015 13:59:59 -0400
Date: Fri, 25 Sep 2015 19:56:54 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?iso-8859-1?Q?St=E9phane?= Graber <stgraber@ubuntu.com>
Subject: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
Message-ID: <20150925175654.GA12504@redhat.com>
References: <20150925135246.27620.97496.stgit@buzz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150925135246.27620.97496.stgit@buzz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/25, Konstantin Khlebnikov wrote:
>
> +struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
>  {
> -	struct file *file;
> +	struct ns_common *ns;
> +	struct fd f;
>  
> -	file = fget(fd);
> -	if (!file)
> +	f = fdget(fd);
> +	if (!f.file)
>  		return ERR_PTR(-EBADF);
>  
> -	if (file->f_op != &ns_file_operations)
> +	if (f.file->f_op != &ns_file_operations)
> +		goto out_invalid;
> +
> +	ns = get_proc_ns(file_inode(f.file));
> +	if (nstype && (ns->ops->type != nstype))
>  		goto out_invalid;
>  
> -	return file;
> +	*fd_ref = f;
> +	return ns;
>  
>  out_invalid:
> -	fput(file);
> +	fdput(f);
>  	return ERR_PTR(-EINVAL);
>  }

Well yes, fdget() makes sense but this is minor.

Honestly, I do not really like the new helper... I understand this
is subjective, so I won't insist. But how about 1/1? We do not need
fd/file at all. With this patch your sys_getvpid() can just use
proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().

Eric, what do you think?

See also "TODO" in the changelog.

Oleg.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933018AbbIYSAX (ORCPT <rfc822;w@1wt.eu>);
	Fri, 25 Sep 2015 14:00:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39867 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S933002AbbIYSAT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 25 Sep 2015 14:00:19 -0400
Date: Fri, 25 Sep 2015 19:57:14 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?iso-8859-1?Q?St=E9phane?= Graber <stgraber@ubuntu.com>
Subject: [PATCH 1/1] ns: introduce proc_get_ns_by_fd()
Message-ID: <20150925175714.GB12504@redhat.com>
References: <20150925135246.27620.97496.stgit@buzz> <20150925175654.GA12504@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150925175654.GA12504@redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Introduce proc_get_ns_by_fd() so that get_net_ns_by_fd() becomes
one-liner. It will have another CLONE_NEWPID user soon.

TODO: proc_get_ns_by_fd() can share some code with proc_ns_fget().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 fs/nsfs.c                |   24 ++++++++++++++++++++++++
 include/linux/proc_ns.h  |    3 +++
 kernel/pid_namespace.c   |    6 ++++++
 net/core/net_namespace.c |   23 +++++++----------------
 4 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/fs/nsfs.c b/fs/nsfs.c
index 99521e7..72474ca 100644
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -136,6 +136,30 @@ out_invalid:
 	return ERR_PTR(-EINVAL);
 }
 
+void *proc_get_ns_by_fd(int fd, int type)
+{
+	struct fd f;
+	struct ns_common *ns;
+	void *ret;
+
+	f = fdget(fd);
+	if (!f.file)
+		return ERR_PTR(-EBADF);
+
+	ret = ERR_PTR(-EINVAL);
+	if (f.file->f_op != &ns_file_operations)
+		goto put;
+
+	ns = get_proc_ns(file_inode(f.file));
+	if (ns->ops->type != type || !ns->ops->get_type)
+		goto put;
+
+	ret = ns->ops->get_type(ns);
+put:
+	fdput(f);
+	return ret;
+}
+
 static const struct super_operations nsfs_ops = {
 	.statfs = simple_statfs,
 	.evict_inode = nsfs_evict,
diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h
index 42dfc61..d956f89 100644
--- a/include/linux/proc_ns.h
+++ b/include/linux/proc_ns.h
@@ -16,6 +16,7 @@ struct proc_ns_operations {
 	struct ns_common *(*get)(struct task_struct *task);
 	void (*put)(struct ns_common *ns);
 	int (*install)(struct nsproxy *nsproxy, struct ns_common *ns);
+	void *(*get_type)(struct ns_common *ns);
 };
 
 extern const struct proc_ns_operations netns_operations;
@@ -66,6 +67,8 @@ static inline int ns_alloc_inum(struct ns_common *ns)
 #define ns_free_inum(ns) proc_free_inum((ns)->inum)
 
 extern struct file *proc_ns_fget(int fd);
+extern void *proc_get_ns_by_fd(int fd, int type);
+
 #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
 extern void *ns_get_path(struct path *path, struct task_struct *task,
 			const struct proc_ns_operations *ns_ops);
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index a65ba13..0c87393 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -388,12 +388,18 @@ static int pidns_install(struct nsproxy *nsproxy, struct ns_common *ns)
 	return 0;
 }
 
+static void *pidns_get_type(struct ns_common *ns)
+{
+	return get_pid_ns(to_pid_ns(ns));
+}
+
 const struct proc_ns_operations pidns_operations = {
 	.name		= "pid",
 	.type		= CLONE_NEWPID,
 	.get		= pidns_get,
 	.put		= pidns_put,
 	.install	= pidns_install,
+	.get_type	= pidns_get_type,
 };
 
 static __init int pid_namespaces_init(void)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 572af00..6465dc0 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -420,22 +420,7 @@ EXPORT_SYMBOL_GPL(__put_net);
 
 struct net *get_net_ns_by_fd(int fd)
 {
-	struct file *file;
-	struct ns_common *ns;
-	struct net *net;
-
-	file = proc_ns_fget(fd);
-	if (IS_ERR(file))
-		return ERR_CAST(file);
-
-	ns = get_proc_ns(file_inode(file));
-	if (ns->ops == &netns_operations)
-		net = get_net(container_of(ns, struct net, ns));
-	else
-		net = ERR_PTR(-EINVAL);
-
-	fput(file);
-	return net;
+	return proc_get_ns_by_fd(fd, CLONE_NEWNET);
 }
 
 #else
@@ -955,11 +940,17 @@ static int netns_install(struct nsproxy *nsproxy, struct ns_common *ns)
 	return 0;
 }
 
+static void *netns_get_type(struct ns_common *ns)
+{
+	return get_net(to_net_ns(ns));
+}
+
 const struct proc_ns_operations netns_operations = {
 	.name		= "net",
 	.type		= CLONE_NEWNET,
 	.get		= netns_get,
 	.put		= netns_put,
 	.install	= netns_install,
+	.get_type	= netns_get_type,
 };
 #endif
-- 
1.5.5.1



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751094AbbI1ENi (ORCPT <rfc822;w@1wt.eu>);
	Mon, 28 Sep 2015 00:13:38 -0400
Received: from mga14.intel.com ([192.55.52.115]:15710 "EHLO mga14.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750935AbbI1END (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 28 Sep 2015 00:13:03 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,601,1437462000"; 
   d="gz'50?scan'50,208,50";a="653408611"
Date: Mon, 28 Sep 2015 12:12:21 +0800
From: kbuild test robot <lkp@intel.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: kbuild-all@01.org, linux-api@vger.kernel.org,
        containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
        Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?iso-8859-1?Q?St=E9phane?= Graber <stgraber@ubuntu.com>
Subject: Re: [PATCH RFC v3 2/2] pidns: introduce syscall getvpid
Message-ID: <201509281251.xxfjYZb4%fengguang.wu@intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <20150925135247.27620.37109.stgit@buzz>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: fengguang.wu@intel.com
X-SA-Exim-Scanned: No (on bee); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Konstantin,

[auto build test results on next-20150925 -- if it's inappropriate base, please ignore]

config: openrisc-or1ksim_defconfig (attached as .config)
reproduce:
  wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 7bea85b3c058d69527d79b94338025f218a0655e
  # save the attached .config to linux build tree
  make.cross ARCH=openrisc 

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/unistd.h:1:0,
                    from arch/openrisc/include/uapi/asm/unistd.h:26,
                    from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:718:0: warning: "__NR_mlock2" redefined
   include/uapi/asm-generic/unistd.h:716:0: note: this is the location of the previous definition
   <stdin>:1307:2: warning: #warning syscall getvpid not implemented
--
   In file included from include/asm-generic/unistd.h:1:0,
                    from arch/openrisc/include/uapi/asm/unistd.h:26,
                    from include/uapi/linux/unistd.h:7,
                    from arch/openrisc/kernel/setup.c:25:
>> include/uapi/asm-generic/unistd.h:718:0: warning: "__NR_mlock2" redefined
   include/uapi/asm-generic/unistd.h:716:0: note: this is the location of the previous definition
--
   In file included from include/asm-generic/unistd.h:1:0,
                    from arch/openrisc/include/uapi/asm/unistd.h:26,
                    from include/uapi/linux/unistd.h:7,
                    from include/linux/syscalls.h:78,
                    from arch/openrisc/kernel/sys_call_table.c:17:
>> include/uapi/asm-generic/unistd.h:718:0: warning: "__NR_mlock2" redefined
   include/uapi/asm-generic/unistd.h:716:0: note: this is the location of the previous definition
   In file included from include/asm-generic/unistd.h:1:0,
                    from arch/openrisc/include/uapi/asm/unistd.h:26,
                    from arch/openrisc/kernel/sys_call_table.c:27:
   include/uapi/asm-generic/unistd.h:716:0: warning: "__NR_mlock2" redefined
   include/uapi/asm-generic/unistd.h:718:0: note: this is the location of the previous definition
>> include/uapi/asm-generic/unistd.h:718:0: warning: "__NR_mlock2" redefined
   include/uapi/asm-generic/unistd.h:716:0: note: this is the location of the previous definition
   include/uapi/asm-generic/unistd.h:719:1: error: '__NR_getvpid' undeclared here (not in a function)
   include/uapi/asm-generic/unistd.h:719:1: error: array index in initializer not of integer type
   include/uapi/asm-generic/unistd.h:719:1: error: (near initialization for 'sys_call_table')
--
   kernel/time/Kconfig:155:warning: range is invalid
   In file included from include/asm-generic/unistd.h:1:0,
                    from arch/openrisc/include/uapi/asm/unistd.h:26,
                    from <stdin>:2:
>> include/uapi/asm-generic/unistd.h:718:0: warning: "__NR_mlock2" redefined
   include/uapi/asm-generic/unistd.h:716:0: note: this is the location of the previous definition
   <stdin>:1307:2: warning: #warning syscall getvpid not implemented

vim +/__NR_mlock2 +718 include/uapi/asm-generic/unistd.h

   702	#define __NR_seccomp 277
   703	__SYSCALL(__NR_seccomp, sys_seccomp)
   704	#define __NR_getrandom 278
   705	__SYSCALL(__NR_getrandom, sys_getrandom)
   706	#define __NR_memfd_create 279
   707	__SYSCALL(__NR_memfd_create, sys_memfd_create)
   708	#define __NR_bpf 280
   709	__SYSCALL(__NR_bpf, sys_bpf)
   710	#define __NR_execveat 281
   711	__SC_COMP(__NR_execveat, sys_execveat, compat_sys_execveat)
   712	#define __NR_userfaultfd 282
   713	__SYSCALL(__NR_userfaultfd, sys_userfaultfd)
   714	#define __NR_membarrier 283
   715	__SYSCALL(__NR_membarrier, sys_membarrier)
   716	#define __NR_mlock2 284
   717	__SYSCALL(__NR_mlock2, sys_mlock2)
 > 718	#define __NR_mlock2 285
   719	__SYSCALL(__NR_getvpid, sys_getvpid)
   720	
   721	#undef __NR_syscalls
   722	#define __NR_syscalls 286
   723	
   724	/*
   725	 * All syscalls below here should go away really,
   726	 * these are provided for both review and as a porting

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

--YiEDa0DAkWCtVeE4
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=".config.gz"
Content-Transfer-Encoding: base64

H4sICJW9CFYAAy5jb25maWcAjFxLc9s4Er7Pr2Bl9jBzyMTvcWrLBxAERaxIggZASfaFpchM
oootqfSYmfz7bYCU+GrIc0jFRDcar0b31w1Av/7yq0cO+/XbfL9czF9ff3rfylW5ne/LF+/r
8rX8rxcILxXaYwHXfwBzvFwd/vm03pSr7XK38G7+uP7j4uN2ceWNy+2qfPXoevV1+e0AEpbr
1S+//kJFGvJRITKWSq7ow89jSZLkzUdEJqwIElIQraVqyuVUsaQYsZRJTguV8TQWdAz0X70O
x4xGIxIEBYlHQnIdJd5y563We29X7o+yjlKiKeOjSDeNpKLgIhNSFwnJmmItCWUFl49hTEaq
UHlmeBr6UR5VedKUBiys/4q50g8fPr0uv3x6W78cXsvdp//kKUlYIVnMiGKf/ljYyfpwrAtt
FVMhzfhg5n71RnYpXs0gDptmLn0pxiwtRFqopNVfnnJdsHRSEGkaT7h+uL46EqkUShVUJBmP
2cOH9fb66uOrWcqPH5q5rMmFZkojEwhTT+IJk4qL9OHDB6y4ILkWnckgeayLSChtRv7w4bfV
elX+3mpTPakJz2i7uRMtE4rPiuQxZzlDGcaBnyukp9VoE5YI+WRUitCorTNhRNIgZkjFXLGY
+21ekoPitzntysBKebvDl93P3b58a1bmqBJmITMpfDbUFkNSkZjiFBrx9opCSSASwtP2TjFd
r4sNB6KQZo+wCUu1OmqSXr6V2x3WZc3pGFSJQZ+6WyJ6NvqQiLQ9G1CYQRsi4BSZvaoWh/71
JHVEwOaDHaCg5QSUZjC1NMs/6fnuh7eHPnvz1Yu328/3O2++WKwPq/1y9a3XeahQEEpFnmqe
jtpN+Sowy0AZKANwaFSHNFFjpYke9kTS3FPYjKVPBdA6VojmBZvB1GD7RvWYbYumCtofIwr6
E8f19OOdloxZTmuknHJMl0B9WeELgY/ez3kcFD5Pr/AtyMfVH6g5MNVD0GYe6ofLm5YdGUmR
ZwoVSCNGx5ngqTZKoIXEe2+shcpgbLgUBWICa2xsUzjPkwoVmKBMMko0C/BZYjF5Qgbnx2Oo
OrFGVQZdIytJAoKVyCVlxg42woJi9MwzRBxQfKBctTxbUMTPCekUzJ57dNH7vmmrEaXgVWET
8WdWhEIWCv7AtO9JUR03gkgKZpqnImCq539zHlzeNWV+FjYflXI33z3eBKw8B+Mp2x1UI6YT
0HXbBVBovHNmKit6p67tNVazMf5AUE8JZv8zCfo1bg0lH7WGEoewtWTLRvngjIswj1uzFOaa
zdodYpnAR8BHKYnDoLPBjWULcYWzdtlBgxk/N1cROLSOa+ICYSPBhMNwajmqXcEskHXI3faP
a8gSn0jJu4sIhSwIurvHWsca72Xl9ut6+zZfLUqP/VWuwFITsNnU2GpwOZVJr0RNkmr0hbXV
PdvfASFEA8gZ47s6Jr6DkPvYrMXC7ymWBsAYEE0KAC085GAcuMPMgvMIeQxeBaXm1sXjo7Ab
6u7GB0hGYlARY62ocURIFy0vkTSqrHkkxLi3z8EfgNGUQjMKFhNbOxHkMfhUWGGr38asNcqc
jTTxATTEMP2gEVc1uqRi8vHLfAdI/0e1lpvtGjB/5WEbLTMdi4gqDH89I9Bdx6a0YzkCEQPo
qYiYhEXHjCIAbrPN2obIbkWVGGtw0Rtce06qImP2AKLHguD7qebK03McNXLFl7GWAB78BHAd
Az9yclxXarJRbtnTgmb7G9yGzBMEPTxlNvqxYwHM08F9NV0yEtT0czS07lQalOCo3CbWtRso
DUDkmcmBdci260W526233v7npoJxX8v5/rAtd62gUF6Oi8uri4umyWOcaIEJIK0i0L4JVy5/
7JZvH2qE+Drf7TzOPb7a7beHhYk0d8NQs9JFnipdhOEl0kSLHp+ng3s7Sw/4pOVLn4tLO6Q2
ar66vcD3y3NxfeEkgZwLzGA8PwClj4YiaeAw6g0ZSzINUDxl7W4dyyciBntM5JPDBlouRC7E
xbpySa2CwiAL40u6wbSdK+Nh+vG7JRh4aqrwNBRWAGbIsxiMaaatFgLmVw83p3DPuAxqrHgL
kfCRJHVRM5boCSKBIJCFrowz0s4zzJK1XCbsf2jN8lhhWYVjiJvAcKHR1Ip/uLn4fHeKgBgs
DqAnG6iMOx6cxoykFKJTHATThKDlz5kQuBV69nPc0D1bmyocIN9ElBkZMeuAxj1/11d7iOhU
BnBTFoGaNRNOk8BYCwOI7S4Nyi+Hb9/AmXjrTW+H/i9PMvCewpizKp4NAGBSlvXX69Qmg9ZO
HAbOVXHEwOywf8rFYT//8lra7JVnocm+1TREOmGijY9s9RzAYBGYPh0X07jQCEwma+ei6qqK
Sp7pgQoTkTsirKpaAsPAMhXQtmm6FTAzfYza03L/93r7A51DUPgx63SjKgFbRLDly1PewbPm
e8B7os5CmVi4iAdn0MyYYWETT7t94lkVGlCi8NkBBgCssAlABSCS044WgS1L8TDPdIZn/Bxx
ZNaXJfnsDE+h8zRl+K5STykslBhzB9gzEvLgrAjDEgo84jeTVpDITYNI2E3kmTF/brpdyjM9
s0zv0a2QxFh2sBCpMonQf8X8r8X6jJ2RGEvhJjoUXtMMFi0dnfSrE6EdiT7HTeKJgebvskyZ
0lMhcMN74orgr3c41PssT36M+4QTy4SNCK6mJxYTGZqA4DxX/E5fIJTDV+XE8cQcWn3i4DH4
DMHf6W9A350YGmA6cLTnEIAgWelj5YcP23K1/tCVmgS3LizPs8mda5Ob9H2hGHhuR/xqNDbT
0HBMlOIhjrmOggCv2GQCxH9J5gpDgRlCsjOWM6CO2QOaohqnycCxKK5kPWBBtDy+crTgSx6M
MKRn/and2Yq0N+0kJmlxf3F1+YjKCxhNHUYkjumVYwZwn0A0ifH1m13d4k2QDM9LZJFwdYsz
xsx4bm+cqmKhPT5cirfnw0IQA0MnKNlAqomack3xrTlR5vBAOx0d7NexBbtnGZzAIsliR8JE
ubFG1d2ATRBlMXQ5A0iongqTomvhtce4B6S8fbnb99Ibdj+O9YjhGaCIJJIEHDd0lOCVuAxw
I+3jekBCGIJ07KspN8eFjpTBlCcE12AZjrkjVWGG/BlfP0p4iBNYFhUxx1UuDfGux9MhAKhj
g7+Wi9ILtsu/qhxhc9y5XNTFnuhD3rzKHkYszmyOEisGFKyj1uEkKI1OslC1rX9VArgDot6m
HGxsGpB4GCNb6SGXyZQAjrQHJuhow6nNRDEsP2dir6k9UGgB/pblMhFNIPnEYcRrBjaRrvMQ
iGujJxj/hCs0QXg6G4QYFORw2s2nmXhXRTC+wBzphEhCxz/svBe7bJ2cLvyXDpKSzW7XWKI5
0K1rACLsBHyhCUy04wAaqCbFYA6/2gIKRmT8hJNMNA6bp1PWSYDBdxWzNN8J7PdepwSsTO+g
qBV3yT4etjOUmPsRyJTB6idPphOoNJbSWKgcNE2Z1XQegEmCu1t6hXaGsUyKxNsdNpv1dt/u
TkUpPl/T2d2gmi7/me/qPNubTe7vvs+35Yu3385XOyPKe12uSu8FxrrcmD/bojUv1LAr5HVf
budemI0IBOnbt79BoPey/nv1up6/eNVViaNJ4Kt9+eolgMCN/lWG4UhTFGzVsLipEq13eyeR
zrcvmMBTUTNBNHKY/1ls89VO4phJsH4FybiThbFoMEGKKl4rTmvBjgsPRBMydc40TFngSBZZ
Yu2Xcf/Z2IPjtuW8k484Hpc1fkykgQuOWvXGVfsxJzF/PpNU0Myh1QmhBv3hiGXmooBI+EsJ
R6QD5P6hXhcWCHsIn2oJfzh6DQ7OVV5M7NTZqyiOHkyYxlFYGvdO/iuFNN652XkvXfcZLGGX
Lr8czNUt9fdyv/juke3i+3JfLkzevcXeGSWA7CKZ3N+zu9nMnSDpcNUpzSxH9AlGZLS+kwUi
JjohhVYY2jfSwcUGQpqjpk41SQsGK++oRMHXQlzfORYiFDsDbDXhS3DRVHSysP4Njr99mhi3
iWO26hzRmQgJevWGPWHP9WWfZn/YkiLNAJuQlIxYYpBHvwdDSTzVLO5u2CPl/up2NkNJEKBO
WPfMPZkkAXqk3K7GqWSdWmN1f397WSTomXWrZkpg/ROOdub++nPrDAhUSFCUzxgQcysGJUKQ
zxRROM0ENRIlKZKovHtvSM1GPit6exOpydgjLlKbaepgCCgC5fwXMp9SkYFudY+sq7IimFoJ
xaPAjpFbUia8GzhzUsiIpw4jxM1JeCwo11hKtyV2yp97O7sqKaa3l45DrBPDNXqSlUVP1X27
CjFx7kHJ0fchBouABqQaOmzY8MD9/uJ65iYngZNW7wgnPSDgJgEpueiPRr2d1HimnTTKwZa5
xzThgIcVc9KNcYVJ5lQ5WVSiqJN4tIluBpr8acz+Gfr9n2fonGZx7u6cZMZBjJ301J7jEffK
gCW+vJjhEW0M6Ifpy4vLy8EEnNCOMWmG2ImIsvvr+7s/3dpidri11y6OkM/YGW0DU1v4XPvE
gaMqBpi2JJ8Vo8yRguhwJQkHoHZOHE1MfNXzqU0kkzlu0sXd4xW7Iw26/rhbvpRervwjTrVc
Zflibo+vt5ZyzL2Ql/kGgD8Wgkx7AK6KWFb2GG+6NBmO34ZHYb97+zVwl97++5ELMRhTV4pG
BcMm+Wpz2A+Rd1MpzfJhPBNBJGFjGP5JeKZKpwPKXJdFuzAiCUNjNQoh1nxh5qqJHo9bXXeU
dIIhA3Oy9/m+yHTXiwDKz7SqjuOyuLq4YM5F8PgyZiNCn6wQXCVgWLAjU5FWeROJ50TSYqRw
RF/drld4UAJ97d11g5IxFA1jpXK7nL+2Vr7bP5sZoO17ATUBgNEFWti6MGqvV8IAcb46ssCJ
qSxyInXrjkKbKs1V5YSdWPqzapnYTIPXdSR/Ox2evssCsRpLOR3MXrpefTQMUGKn0W5hRPFr
Waa/MTgjZMVqju69ylahc7pEWGQx0aGQnfWuqYrS1GHYa446tvifJiPTvX/B+h7bzNz4A2em
3uWEAOUcOVRxEWfvCYEvNgNQUwR8BPgidqTSYOfX11pxe5YB9qjuUuD1o2kBKCEQ+G6UGh8J
qI2TJq8/390MVCqjCeXEWyA2rBkLhX8Z3hOY/fip96qjMs5XFLXJjovrypF0UTBR+AQpPhxM
prA2s2zYPVNWP51a25cWx1oVVWfe4nW9+IGK01lxeXt/Xz3ccDnCCirbm3TO48GWR5y/vCyN
n4RdbRve/dEYR3ulU7LHnMPGNNCiwuDHNccK6uRzJ09qyodpbCdUsWLshe9hqrR8W29/em/z
zQaQg5WA+HIr4M+bWQV03G1U+9xND6auszpLPqbKj2bpDKd8Z7A0ur68nA2HGwbVIMt/NrCe
fchyiYMzMWXSvkKLHXloy0AmjvO1qfMtScRkQvA02JSYgzeBna0r5ZsHWor71qpX3ni9Wi52
nlq+LhfrlefPFz82r/NuUhjqIdIAmZKBOH+7nr8s1m/eblMull+XC48kPmkL83tX5KrpPbzu
l18PK3sx9EwwCctgfROOl4ForjfGRRTTALcxhifidzdXl0WWcJwn0qBJRHF67RQxZknmOFMy
5ETfXX/+00lWye0FrjHEn91eXJwfonkm4NALQ9YcQubr69tZoRXEqO5p0Jm6u/18iZ+yWwbX
loWAJYed5jpBYgFE+/Xby8FKj7bzzXejcYhVDeQQLYbb+VvpfTl8/QqOKRg6ptB1pE7HsXkz
WoAqYJ1pAPmImLdk+HwrkafYeRhESYWIKC8AW2lA5gD7OGlBVkMfvD41haer+RHtnAfk3S1m
R2jKsKyxKc++/9yZ179ePP9pPPZwq5jWnOG5yCx9RhnH7xwYqjWIk55j73KQYORItuZTfGGS
xKGRLFH9y9CtdPYUwhvH9ZbqkQb3AQNqR7ZC0+ryDp4kSkh9nIKLz2cBV5nrKDF37JEJl7o+
Hx46z8lyC4YOWzVTDWa97y3r08nFdr1bf9170c9Nuf048b4dyh2O/gFb9057uoGv2ixXFtz0
dIvaQrU+bB3ZPGtfM+7Ax1H1kKqgyTsMic5xw3Pi0Al+9ZIlNQOoiyMpyGNfzJBdy0WS5K19
2bnCYIleNv9WVpeRVRcOSsA7+3KzXS+waVGa2UuRSSHN69XBvMvN2+5bf64VMP6m7FNVT6w8
+n25+b3xmwHSSp7OuPscGeQVjjnJEoMGQwCQ+JzOtNOl2BfZeADjUP1sit265/Kx+1TaPiXJ
eOf8iJsb0YXL5ACatSebZ4/3wmQ4/cYOtp8Ft4OlCjg6DKWB69mMFFf3aWLCDUcSrs0FdhHX
bJPJG4uUWA53iwYSUsddrYQOvUT7Nd8bgDmIZTCLIMnQDJHVy3a9fOns7zSQgjsyQxMsnROa
S/vVzHYds6p/DIBQ7JjJPkkzwVP1APxUKRWah920blWEqVRFKfqvWEMyrHIiPuZC45GGpVCN
w2rzcDlUN0WIq2ZonvE5aPVNlAKJouh88b2HZ9TgcUm1zLvy8LK2TySayT7qDJicIuykDm3R
uI8j28T+I2NbaF+UQNTBAdwNxMH2jQPZvXVX0821ifaNLRszNp/H+1xNAGOvc6H60eOZmRtC
OEzPAXvEvu0zylD9BzJC7OzNvO6wWlgdC3e6JyRJR2xQs5mOwSv4E1Cpwvyu3CPRCux+T656
39ftflQlzhmyZMdFVPNGe+q68hkqDNSObH63+rGIpldmj/Y/odVut08/O9F4Kpl1LHtVUiUc
8NUy1xUd8025g5DSzFlHBMRFI+6lTePhLlXl4rBd7n+2nvSc+MfMmW6nuQRECviSKeu7NHga
V16x4j1LRLX4eDG+aY20zuH71NYtSyqfMvu7L9Vgtj83+7W3WAM0BP/xvXzd2BtVHWbzUz0k
a10H6BRfDcsZCR7ekMIhqx+PKc8iJockCJaigRRTOGSV4Er6nFCGMh7nZlDBvs1BBtPqYKNj
tThFkKWpidW9EDlopy7H5PVfcaEVC4hK7BNxc/NSIVJG4eXVfZJjzrfmSM3vJ/T7ZQqHwzdW
zf6oD9KQ/Q+HDMcuv88C/jViKY6vapb+FdMKwxz238uV+SUsc4mKrRZGk00S6e/l/rtHdrv1
YmlJwXw/71yDrTtPHZcy60k8T6YROGtydZGJ+Ony+gJ/Z1DzKvbIsevwNZmBIJ7yCSxIlUmz
kdjb+qV3e7du2D87VdThM09kh808dgWP3WtyLPHjq9MGOt+32f8buZbeNnIYfN9fkeMu0A3q
xA2yhz3My/HE86pmHCe+DNLUSIw0D9gOsP33S1Kap0g5p6YiLY0oiqIo8mNwe+b3+yd5rnxC
WWMKgAoys0Y58hU3o05NPt4jXKi5T1DBufBq0ec4wlBNvoZSsr5RNzRsTuF+QtHSkPcJWrL7
1zEoItzxpehoY/PSEMzLMY4LPsWo4zj7xtdldRznZ84+yrk3kZUDqDACox5A+CaEPhtrc6Um
/zg5VsWoC6042/enwbt2e/BxRtrLlr5QS9dwqMC5nH6Sr2axW2sCL42SJOavPS1PWTkVAxmc
ixUKETRDntG/Lo7F3FsLqB/NsnlJ6bkVojHJblMsPNK3dFWMAFDsw8gpTbgGjBdFa8fby/tu
s99rpEVbglgRIdxmNMtaquhpjPNayHzX5MupU6WTtVPXgDxnglv3rz/fXk6yj5cfm51BQDzw
E/SyMq6DQrFwBY0QlI9hp2xpuSZEIXtvbyRNO2I9iWl0Ntoc1rjXWN6CiDgqL+4YY4L+GpYM
HB2/ZSyNN/kpZiWkm4350LV2nJOr1tnf7A4YYgS3aE85X/vt4ysBvZw8PG0enkfldn6cecpk
MsysxU+2P3b3u98nu7ePw/a1n/jkxxVWYqly4DN2yEkdnbuLNvihlYI73l09w4IXE+dhWJIo
E6hU6F/FSWmTiiDGkHAf86QFdpSah5oXgPsIuiGsTjCRzGVQO10BGKha1lyiGHkZo284PwN7
lcyEAizDkMRB5N9dMj/VFGnbE4unVrJVQg5feA8AKv8KCkbM6VIFkmcRXEzrSAJZIeBPrVwG
kswsHB9Nptwat/TAmmKRsoGA6kVB1lO2/XaNzeP/17eXF1YbBXoLmzf2LqZWo6dSrq2aL1Pf
IpSFrsoYtvrBdX/1Tasw725uYxDEHmUIhtgj9EERB/y50N6bML6Nwu7rYxRhUzgY6nu/doJq
CO296lU5uLB9WbZvrw1Jy3tGccgqvhnebXMVCooThtwBAio9CweZ9qVBQOJ1tfmYEoFx4OZn
WVaD1vd031hkan3fbV8Pz5RT9PNls3/kYlI66YyeybjAJ8gcw7xJfkXocm0kZNq5KNtfm78J
zJUOhD0N96Dbd9yIOo8IsaDYyUYZRSpWnsqOoXsa1nRZVjZgkOGZKYRkxt7+nXw9m/YkXilE
pynTeowy2e16OCRpBE/Icl1mcJBglkXq50Lhu54tG48zEET60+1MqzIizCsMPqeeVM9vuieg
vFXkLRokKpY59a5iCuYPi1MHXemixrZkQ2dutWBPA81BxaA01lICWNRdIqOMTqV5cv86kiIN
RhwIkggHtxTB11w3/EJpokGMRpBXbjkIpLwbC59iZglBOXOf0pBdnzwflQH/0SJnnSRvD88f
73q3zO9fHwdbBAPnS8SrshEhe0MgsZ4vMw05zD8+eBmsOChRnhecCg7o9Y2XLKMOmFET0TLk
y6pr1nB0NMNhlSo2i9uayBYQ8+jXeo2jLLS380i0+FWLKBJRU5pnfw74GUXfwy/7c2/yG/Zf
Tl4+Dpv/NvDH5vBwenr6l223OlRL18IbJHuXLh7tRJ884HTBNB1s5l1UXxWMdyIk/SO0HqhT
heXn48N81OtCb0jXuLGzgyI+xlEKBcZEpEfZWAKR1TyBisIIy8WYZxiE3+atloKNK6JzoztU
auhtArGWyoKPCZGwuz/F5Ab4/l46XsEaGdWRUlQneq1PDJZZP+6wPFpgCL4Oh3hlY6jgBGgx
61JKjMMUOlPygeB68pR9gjYX6SRyMEO1mw0OOUS6EOmt08a568N5zaNbxOuQGdBPQGguwh8R
QJOQbwGMVc6XWBODwht/NQbmagRIQO1hHpTDImkt+4VQZINEutIHeSEVDwKLX/C3R/37cIyR
3vkLUeoWHtpXMFHyu6aXFsnQyP0Ps5YCYpJkAAA=

--YiEDa0DAkWCtVeE4--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932107AbbI1IVP (ORCPT <rfc822;w@1wt.eu>);
	Mon, 28 Sep 2015 04:21:15 -0400
Received: from forward-corp1g.mail.yandex.net ([95.108.253.251]:51469 "EHLO
	forward-corp1g.mail.yandex.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1756816AbbI1IVN (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 28 Sep 2015 04:21:13 -0400
Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
To: Oleg Nesterov <oleg@redhat.com>
References: <20150925135246.27620.97496.stgit@buzz>
 <20150925175654.GA12504@redhat.com>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?UTF-8?Q?St=c3=a9phane_Graber?= <stgraber@ubuntu.com>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Message-ID: <5608F873.6050305@yandex-team.ru>
Date: Mon, 28 Sep 2015 11:21:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150925175654.GA12504@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 25.09.2015 20:56, Oleg Nesterov wrote:
> On 09/25, Konstantin Khlebnikov wrote:
>>
>> +struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
>>   {
>> -	struct file *file;
>> +	struct ns_common *ns;
>> +	struct fd f;
>>
>> -	file = fget(fd);
>> -	if (!file)
>> +	f = fdget(fd);
>> +	if (!f.file)
>>   		return ERR_PTR(-EBADF);
>>
>> -	if (file->f_op != &ns_file_operations)
>> +	if (f.file->f_op != &ns_file_operations)
>> +		goto out_invalid;
>> +
>> +	ns = get_proc_ns(file_inode(f.file));
>> +	if (nstype && (ns->ops->type != nstype))
>>   		goto out_invalid;
>>
>> -	return file;
>> +	*fd_ref = f;
>> +	return ns;
>>
>>   out_invalid:
>> -	fput(file);
>> +	fdput(f);
>>   	return ERR_PTR(-EINVAL);
>>   }
>
> Well yes, fdget() makes sense but this is minor.
>
> Honestly, I do not really like the new helper... I understand this
> is subjective, so I won't insist. But how about 1/1? We do not need
> fd/file at all. With this patch your sys_getvpid() can just use
> proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().

Hmm. My version has 0 or 2 atomic ops per get-put sequence.
Your version: 2 or 4 atomic ops. Plus even in worst case pinning by
struct fd theoretically scales better because it touches refcount at
struct file: there're might be many of them for one namespace.

>
> Eric, what do you think?
>
> See also "TODO" in the changelog.
>
> Oleg.
>


-- 
Konstantin

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934180AbbI1Q3u (ORCPT <rfc822;w@1wt.eu>);
	Mon, 28 Sep 2015 12:29:50 -0400
Received: from out02.mta.xmission.com ([166.70.13.232]:43364 "EHLO
	out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933752AbbI1Q3q (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 28 Sep 2015 12:29:46 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?Q?St=C3=A9phane?= Graber <stgraber@ubuntu.com>
References: <20150925135246.27620.97496.stgit@buzz>
	<20150925135247.27620.37109.stgit@buzz>
Date: Mon, 28 Sep 2015 11:22:21 -0500
In-Reply-To: <20150925135247.27620.37109.stgit@buzz> (Konstantin Khlebnikov's
	message of "Fri, 25 Sep 2015 16:52:47 +0300")
Message-ID: <87a8s6a4zm.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-AID: U2FsdGVkX1/bqnPJGEZrXgs3+NQGJg4/WkiAEQ3JcQg=
X-SA-Exim-Connect-IP: 67.3.201.231
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.0 TVD_RCVD_IP Message was received from an IP address
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
	*  1.2 LotsOfNums_01 BODY: Lots of long strings of numbers
	*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	*      [score: 0.5000]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa06 1397; Body=1 Fuz1=1 Fuz2=1]
	*  1.0 T_XMDrugObfuBody_08 obfuscated drug references
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: **;Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
X-Spam-Relay-Country: 
X-Spam-Timing: total 843 ms - load_scoreonly_sql: 0.06 (0.0%),
	signal_user_changed: 3.5 (0.4%), b_tie_ro: 2.5 (0.3%), parse: 1.02 (0.1%),
	extract_message_metadata: 29 (3.4%), get_uri_detail_list: 5 (0.6%),
	tests_pri_-1000: 10 (1.1%), tests_pri_-950: 1.80 (0.2%), tests_pri_-900: 1.22
	(0.1%), tests_pri_-400: 55 (6.5%), check_bayes: 53 (6.3%), b_tokenize: 26
	(3.1%), b_tok_get_all: 13 (1.6%), b_comp_prob: 6 (0.7%), b_tok_touch_all: 3.9
	(0.5%), b_finish: 1.08 (0.1%), tests_pri_0: 731 (86.8%), tests_pri_500: 6
	(0.7%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH RFC v3 2/2] pidns: introduce syscall getvpid
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Konstantin Khlebnikov <khlebnikov@yandex-team.ru> writes:

> pid_t getvpid(pid_t pid, int source, int target);
>
> This syscall converts pid from source pid-namespace into pid visible
> in target pid-namespace. If pid is unreachable from target namespace
> then getvpid() returns zero.

Two minor things.

Can we please call this translate_pid? getvpid does not really cover
what this syscall does.

Can you please split wiring up into a separate patch?  You goofed it
up this round and it just adds noise in reviewing the core syscall.

> Namespaces are defined by file descriptors pointing to entries in
> proc (/proc/[pid]/ns/pid). If argument is negative then current pid
> namespace is used.
>
> If pid is negative then getvpid() returns pid of parent task for -pid.
>
> Possible error codes:
> ESRCH    - task not found
> EBADF    - closed file descriptor
> EINVAL   - not pid-namespace file descriptor
>
> Such conversion is required for interaction between processes from
> different pid-namespaces. For example system service at host system
> who provide access to restricted set of privileged operations for
> clients from containers have to convert pids back and forward.
>
> Recent kernels expose virtual pids in /proc/[pid]/status:NSpid, but
> this interface works only in one way and even that is non-trivial.
>
> Other option is passing pids with credentials via unix socket, but
> this solution requires a lot of preparation and CAP_SYS_ADMIN for
> sending arbitrary pids.
>
> This syscall works in both directions, it's fast and simple.
>
> Examples:
> getvpid(pid, ns, -1)      - get pid in our pid namespace
> getvpid(pid, -1, ns)      - get pid in container
> getvpid(pid, -1, ns) > 0  - is pid is reachable from container?
> getvpid(1, ns1, ns2) > 0  - is ns1 inside ns2?
> getvpid(1, ns1, ns2) == 0 - is ns1 outside ns2?
> getvpid(1, ns, -1)        - get init task of pid-namespace
> getvpid(-1, ns, -1)       - get reaper of init task in parent pid-namespace
> getvpid(-pid, -1, -1)     - get ppid by pid
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>
> --
>
> v1: https://lkml.org/lkml/2015/9/15/411
> v2: https://lkml.org/lkml/2015/9/24/278
> v3:
>  * use proc_ns_fdget()
>  * update description
>  * rebase to next-20150925
>  * fix conflict with mlock2
> ---
>  arch/x86/entry/syscalls/syscall_32.tbl |    1 +
>  arch/x86/entry/syscalls/syscall_64.tbl |    1 +
>  include/linux/syscalls.h               |    1 +
>  include/uapi/asm-generic/unistd.h      |    4 ++-
>  kernel/sys.c                           |   51 ++++++++++++++++++++++++++++++++
>  5 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
> index 143ef9f37932..c36c2c65d204 100644
> --- a/arch/x86/entry/syscalls/syscall_32.tbl
> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> @@ -383,3 +383,4 @@
>  374	i386	userfaultfd		sys_userfaultfd
>  375	i386	membarrier		sys_membarrier
>  376	i386	mlock2			sys_mlock2
> +377	i386	getvpid			sys_getvpid
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
> index 314a90bfc09c..90bbbc7fdbe0 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -332,6 +332,7 @@
>  323	common	userfaultfd		sys_userfaultfd
>  324	common	membarrier		sys_membarrier
>  325	common	mlock2			sys_mlock2
> +326	common	getvpid			sys_getvpid
>  
>  #
>  # 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 a156b82dd14c..dbb5638260b5 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -222,6 +222,7 @@ asmlinkage long sys_nanosleep(struct timespec __user *rqtp, struct timespec __us
>  asmlinkage long sys_alarm(unsigned int seconds);
>  asmlinkage long sys_getpid(void);
>  asmlinkage long sys_getppid(void);
> +asmlinkage long sys_getvpid(pid_t pid, int source, int target);
>  asmlinkage long sys_getuid(void);
>  asmlinkage long sys_geteuid(void);
>  asmlinkage long sys_getgid(void);
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index 1324b0292ec2..2c1123130f90 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -715,9 +715,11 @@ __SYSCALL(__NR_userfaultfd, sys_userfaultfd)
>  __SYSCALL(__NR_membarrier, sys_membarrier)
>  #define __NR_mlock2 284
>  __SYSCALL(__NR_mlock2, sys_mlock2)
> +#define __NR_mlock2 285
> +__SYSCALL(__NR_getvpid, sys_getvpid)
>  
>  #undef __NR_syscalls
> -#define __NR_syscalls 285
> +#define __NR_syscalls 286
>  
>  /*
>   * All syscalls below here should go away really,
> diff --git a/kernel/sys.c b/kernel/sys.c
> index fa2f2f671a5c..1e28a36b84fa 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -46,6 +46,7 @@
>  #include <linux/syscalls.h>
>  #include <linux/kprobes.h>
>  #include <linux/user_namespace.h>
> +#include <linux/proc_ns.h>
>  #include <linux/binfmts.h>
>  
>  #include <linux/sched.h>
> @@ -855,6 +856,56 @@ SYSCALL_DEFINE0(getppid)
>  	return pid;
>  }
>  
> +SYSCALL_DEFINE3(getvpid, pid_t, pid, int, source, int, target)
> +{
> +	struct pid_namespace *source_ns, *target_ns;
> +	struct fd source_fd = {}, target_fd = {};
> +	struct pid *struct_pid;
> +	struct ns_common *ns;
> +	pid_t result;
> +
> +	if (source >= 0) {
> +		ns = proc_ns_fdget(source, CLONE_NEWPID, &source_fd);
> +		result = PTR_ERR(ns);
> +		if (IS_ERR(ns))
> +			goto out;
> +		source_ns = container_of(ns, struct pid_namespace, ns);
> +	} else
> +		source_ns = task_active_pid_ns(current);
> +
> +	if (target >= 0) {
> +		ns = proc_ns_fdget(target, CLONE_NEWPID, &target_fd);
> +		result = PTR_ERR(ns);
> +		if (IS_ERR(ns))
> +			goto out;
> +		target_ns = container_of(ns, struct pid_namespace, ns);
> +	} else
> +		target_ns = task_active_pid_ns(current);
> +
> +	rcu_read_lock();
> +	struct_pid = find_pid_ns(abs(pid), source_ns);
> +
> +	if (struct_pid && pid < 0) {
> +		struct task_struct *task;
> +
> +		task = pid_task(struct_pid, PIDTYPE_PID);
> +		if (task)
> +			task = rcu_dereference(task->real_parent);
> +		struct_pid = task ? task_pid(task) : NULL;
> +	}
> +
> +	if (struct_pid)
> +		result = pid_nr_ns(struct_pid, target_ns);
> +	else
> +		result = -ESRCH;
> +	rcu_read_unlock();
> +
> +out:
> +	fdput(target_fd);
> +	fdput(source_fd);
> +	return result;
> +}
> +
>  SYSCALL_DEFINE0(getuid)
>  {
>  	/* Only we change this so SMP safe */

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934501AbbI1Qof (ORCPT <rfc822;w@1wt.eu>);
	Mon, 28 Sep 2015 12:44:35 -0400
Received: from out02.mta.xmission.com ([166.70.13.232]:46844 "EHLO
	out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S934013AbbI1Qod (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 28 Sep 2015 12:44:33 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
        linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?Q?St=C3=A9phane?= Graber <stgraber@ubuntu.com>
References: <20150925135246.27620.97496.stgit@buzz>
	<20150925175654.GA12504@redhat.com>
Date: Mon, 28 Sep 2015 11:37:08 -0500
In-Reply-To: <20150925175654.GA12504@redhat.com> (Oleg Nesterov's message of
	"Fri, 25 Sep 2015 19:56:54 +0200")
Message-ID: <871tdi8pqj.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-AID: U2FsdGVkX1+khmBbLUrKfunRL7TMb+oc7+B02q3CHhU=
X-SA-Exim-Connect-IP: 67.3.201.231
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.0 TVD_RCVD_IP Message was received from an IP address
	*  1.0 XMGappySubj_02 Gappier still
	*  0.5 XMGappySubj_01 Very gappy subject
	*  1.5 XMNoVowels Alpha-numberic number with no vowels
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
	*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	*      [score: 0.4890]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa07 1397; Body=1 Fuz1=1 Fuz2=1]
	*  0.0 T_TooManySym_01 4+ unique symbols in subject
	*  0.0 T_TooManySym_02 5+ unique symbols in subject
	*  0.0 T_TooManySym_03 6+ unique symbols in subject
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: **;Oleg Nesterov <oleg@redhat.com>
X-Spam-Relay-Country: 
X-Spam-Timing: total 382 ms - load_scoreonly_sql: 0.03 (0.0%),
	signal_user_changed: 3.0 (0.8%), b_tie_ro: 2.1 (0.6%), parse: 1.34 (0.4%),
	extract_message_metadata: 5 (1.3%), get_uri_detail_list: 3.0 (0.8%),
	tests_pri_-1000: 6 (1.5%), tests_pri_-950: 1.80 (0.5%), tests_pri_-900: 1.54
	(0.4%), tests_pri_-400: 41 (10.7%), check_bayes: 39 (10.3%), b_tokenize: 12
	(3.2%), b_tok_get_all: 10 (2.5%), b_comp_prob: 3.0 (0.8%), b_tok_touch_all:
	2.6 (0.7%), b_finish: 0.78 (0.2%), tests_pri_0: 303 (79.5%), tests_pri_500:
	4.3 (1.1%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Oleg Nesterov <oleg@redhat.com> writes:

> On 09/25, Konstantin Khlebnikov wrote:
>>
>> +struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
>>  {
>> -	struct file *file;
>> +	struct ns_common *ns;
>> +	struct fd f;
>>  
>> -	file = fget(fd);
>> -	if (!file)
>> +	f = fdget(fd);
>> +	if (!f.file)
>>  		return ERR_PTR(-EBADF);
>>  
>> -	if (file->f_op != &ns_file_operations)
>> +	if (f.file->f_op != &ns_file_operations)
>> +		goto out_invalid;
>> +
>> +	ns = get_proc_ns(file_inode(f.file));
>> +	if (nstype && (ns->ops->type != nstype))
>>  		goto out_invalid;
>>  
>> -	return file;
>> +	*fd_ref = f;
>> +	return ns;
>>  
>>  out_invalid:
>> -	fput(file);
>> +	fdput(f);
>>  	return ERR_PTR(-EINVAL);
>>  }
>
> Well yes, fdget() makes sense but this is minor.
>
> Honestly, I do not really like the new helper... I understand this
> is subjective, so I won't insist. But how about 1/1? We do not need
> fd/file at all. With this patch your sys_getvpid() can just use
> proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().
>
> Eric, what do you think?

At some level I don't care this is not exposed to userspace.

However since we are going several rounds with this.

Of the existing uses several of them sleep, which unfortunately means we
can not use rcu locking for everything.  The network namespace ones wind
up taking a reference to struct net because the have the legacy pid case
to deal with.  Which makes we can not use fdget for all callers either.

For this translate_pid rcu locking is sufficient, rcu locking is easy
and doing any more than rcu locking just seems silly.  So let me
respectfully suggest.

struct ns_common *ns_by_fd_rcu(int fd, int type)
{
	struct files_struct *files = current->files;
	struct file *file;
	struct ns_common *ns;
	void *ret;

	file = fcheck_files(files, fd);
        if (!file)
		return ERR_PTR(-EBADF);

	if (file->f_mode & FMODE_PATH)
		return ERR_PTR(-EINVAL);

	if (file->f_op != &ns_file_operations)
        	return ERR_PTR(-EINVAL);

	ns = get_proc_ns(file_inode(file));
	if (ns->ops->type != type)
		return ERR_PTR(-EINVAL);

	return ns;
}

struct pid_namespace *pidns_by_fd_rcu(int fd)
{
	struct ns_common *ns = ns_by_fd_rcu(fd, CLONE_NEWPID);
        if (IS_ERR(ns))
		return ERR_CAST(ns);
	return container_of(ns, struct pid_namespace, ns);
}

SYSCALL_DEFINE3(translate_pid, pid_t, pid_nr, int, sourcefd, int, targetfd)
{
	struct pid_namespace *source, *target;
	struct pid *pid;
	pid_t result;

	rcu_read_lock();

	if (sourcefd >= 0)
        	source = pidns_by_fd_rcu(sourcefd);
	else
		source = task_active_pid_ns(current);

	if (targetfd >= 0)
        	target = pidns_by_fd_rcu(targetfd);
	else
		target = task_active_pid_ns(current);

	pid = find_pid_ns(pid_nr, source);
        result = pid_nr_ns(pid, target);
        if (result == 0)
		result = -ESRCH;          

	rcu_read_unlock();

	return result;
}

Eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934457AbbI1RFU (ORCPT <rfc822;w@1wt.eu>);
	Mon, 28 Sep 2015 13:05:20 -0400
Received: from out02.mta.xmission.com ([166.70.13.232]:51756 "EHLO
	out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S934418AbbI1RFE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 28 Sep 2015 13:05:04 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?Q?St=C3=A9phane?= Graber <stgraber@ubuntu.com>
References: <20150925135246.27620.97496.stgit@buzz>
	<20150925135247.27620.37109.stgit@buzz>
Date: Mon, 28 Sep 2015 11:57:39 -0500
In-Reply-To: <20150925135247.27620.37109.stgit@buzz> (Konstantin Khlebnikov's
	message of "Fri, 25 Sep 2015 16:52:47 +0300")
Message-ID: <87d1x25vng.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-AID: U2FsdGVkX1/T3z3CODh45KCXy9in6BpzytUQDwcjK3I=
X-SA-Exim-Connect-IP: 67.3.201.231
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.0 TVD_RCVD_IP Message was received from an IP address
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
	*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	*      [score: 0.5000]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa05 1397; Body=1 Fuz1=1 Fuz2=1]
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ;Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
X-Spam-Relay-Country: 
X-Spam-Timing: total 652 ms - load_scoreonly_sql: 0.06 (0.0%),
	signal_user_changed: 5 (0.8%), b_tie_ro: 3.9 (0.6%), parse: 1.40 (0.2%),
	extract_message_metadata: 12 (1.9%), get_uri_detail_list: 2.1 (0.3%),
	tests_pri_-1000: 4.1 (0.6%), tests_pri_-950: 1.00 (0.2%), tests_pri_-900:
	0.77 (0.1%), tests_pri_-400: 18 (2.8%), check_bayes: 17 (2.7%), b_tokenize:
	4.7 (0.7%), b_tok_get_all: 6 (0.9%), b_comp_prob: 1.69 (0.3%),
	b_tok_touch_all: 3.1 (0.5%), b_finish: 0.69 (0.1%), tests_pri_0: 599 (91.9%),
	tests_pri_500: 6 (0.9%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH RFC v3 2/2] pidns: introduce syscall getvpid
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Konstantin Khlebnikov <khlebnikov@yandex-team.ru> writes:

> If pid is negative then getvpid() returns pid of parent task for -pid.

Now that I am noticing this.  I don't think I have seen any discussion
about justifying a syscall getting another processes parent pid.  My
apologies if I just missed it.

Why do we want the the parent pid?  We can we usefully do with it?
Is proc really that bad of an interface?

Fetching a parent pid feels like a separate logical operation
from pid translation.  Which makes me a bit uneasy about this
part of the conversation.

> Examples:
> getvpid(pid, ns, -1)      - get pid in our pid namespace
> getvpid(pid, -1, ns)      - get pid in container
> getvpid(pid, -1, ns) > 0  - is pid is reachable from container?
> getvpid(1, ns1, ns2) > 0  - is ns1 inside ns2?
> getvpid(1, ns1, ns2) == 0 - is ns1 outside ns2?
> getvpid(1, ns, -1)        - get init task of pid-namespace
> getvpid(-1, ns, -1)       - get reaper of init task in parent pid-namespace
> getvpid(-pid, -1, -1)     - get ppid by pid

As I step back and pay attention to this case I am half wondering if
perhaps what would be most useful is a file descriptor that refers
to a pid and an updated set of system calls that takes pid file
descriptors instead of pids.

Something like:

    getpidfd(int pidnsfd, pid_t pid);
    
    waitfd(int pidfd, int *status, int options, struct rusage *rusage);
    
    killfd(int pidfd, int sig);
    
    clonefd(...);
    
And perhaps:
    pid_nr_ns(int pidnsfd, int pidfd);

    parentfd(int pidfd);

Eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934655AbbI2Qqf (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Sep 2015 12:46:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:48434 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751508AbbI2QqZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Sep 2015 12:46:25 -0400
Date: Tue, 29 Sep 2015 18:43:15 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
        linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?iso-8859-1?Q?St=E9phane?= Graber <stgraber@ubuntu.com>
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
Message-ID: <20150929164315.GA16734@redhat.com>
References: <20150925135246.27620.97496.stgit@buzz> <20150925175654.GA12504@redhat.com> <871tdi8pqj.fsf@x220.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <871tdi8pqj.fsf@x220.int.ebiederm.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/28, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > Honestly, I do not really like the new helper... I understand this
> > is subjective, so I won't insist. But how about 1/1? We do not need
> > fd/file at all. With this patch your sys_getvpid() can just use
> > proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().
> >
> > Eric, what do you think?
>
> At some level I don't care this is not exposed to userspace.

I agree, this is minor. But you know, the kernel is already complicated
too much, we should try to simplify/cleanup everything we can ;)

> Of the existing uses several of them sleep, which unfortunately means we
> can not use rcu locking for everything.  The network namespace ones wind
> up taking a reference to struct net because the have the legacy pid case
> to deal with. Which makes we can not use fdget for all callers either.

And that is why 1/1 adds proc_get_ns_by_fd/get_type which can also be used
by the network namespace.

> For this translate_pid rcu locking is sufficient, rcu locking is easy
> and doing any more than rcu locking just seems silly.  So let me
> respectfully suggest.
>
> struct ns_common *ns_by_fd_rcu(int fd, int type)
> {
> 	struct files_struct *files = current->files;
> 	struct file *file;
> 	struct ns_common *ns;
> 	void *ret;
>
> 	file = fcheck_files(files, fd);
>         if (!file)
> 		return ERR_PTR(-EBADF);
>
> 	if (file->f_mode & FMODE_PATH)
> 		return ERR_PTR(-EINVAL);
>
> 	if (file->f_op != &ns_file_operations)
>         	return ERR_PTR(-EINVAL);
>
> 	ns = get_proc_ns(file_inode(file));
> 	if (ns->ops->type != type)
> 		return ERR_PTR(-EINVAL);
>
> 	return ns;
> }

OK, I won't insist, this too looks better to me than proc_ns_fdget(&fd_ref).

And in any case fcheck_files() makes more sense than fdget(), somehow I did
not think about this when I sent 1/1.

Hmm. and after the quick look at cleanup_net() I can't understand whether
get_net_ns_by_fd() can use ns_by_fd_rcu() + maybe_get_net(to_net_ns()) or
not... Can it?

Oleg.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S935065AbbI2RjA (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Sep 2015 13:39:00 -0400
Received: from out01.mta.xmission.com ([166.70.13.231]:40095 "EHLO
	out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932527AbbI2Riw (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Sep 2015 13:38:52 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
        linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?Q?St=C3=A9phane?= Graber <stgraber@ubuntu.com>
References: <20150925135246.27620.97496.stgit@buzz>
	<20150925175654.GA12504@redhat.com>
	<871tdi8pqj.fsf@x220.int.ebiederm.org>
	<20150929164315.GA16734@redhat.com>
Date: Tue, 29 Sep 2015 12:30:39 -0500
In-Reply-To: <20150929164315.GA16734@redhat.com> (Oleg Nesterov's message of
	"Tue, 29 Sep 2015 18:43:15 +0200")
Message-ID: <874mid16bk.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-AID: U2FsdGVkX1/cGHsLGkflwbI6i3Nkj+WaSPLUXLDFGYE=
X-SA-Exim-Connect-IP: 67.3.201.231
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.0 TVD_RCVD_IP Message was received from an IP address
	*  0.5 XMGappySubj_01 Very gappy subject
	*  1.5 XMNoVowels Alpha-numberic number with no vowels
	*  1.0 XMGappySubj_02 Gappier still
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG
	*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	*      [score: 0.4701]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa03 1397; Body=1 Fuz1=1 Fuz2=1]
	*  0.0 T_TooManySym_01 4+ unique symbols in subject
	*  0.0 T_TooManySym_03 6+ unique symbols in subject
	*  0.0 T_TooManySym_02 5+ unique symbols in subject
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: **;Oleg Nesterov <oleg@redhat.com>
X-Spam-Relay-Country: 
X-Spam-Timing: total 922 ms - load_scoreonly_sql: 0.06 (0.0%),
	signal_user_changed: 4 (0.4%), parse: 1.62 (0.2%), extract_message_metadata:
	6 (0.7%), get_uri_detail_list: 4 (0.4%), tests_pri_-1000: 6 (0.7%),
	tests_pri_-950: 2 (0.2%), tests_pri_-900: 1.56 (0.2%), tests_pri_-400: 42
	(4.5%), check_bayes: 40 (4.3%), tests_pri_0: 845 (91.7%), tests_pri_500: 8
	(0.8%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Oleg Nesterov <oleg@redhat.com> writes:

> On 09/28, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <oleg@redhat.com> writes:
>>
>> > Honestly, I do not really like the new helper... I understand this
>> > is subjective, so I won't insist. But how about 1/1? We do not need
>> > fd/file at all. With this patch your sys_getvpid() can just use
>> > proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().
>> >
>> > Eric, what do you think?
>>
>> At some level I don't care this is not exposed to userspace.
>
> I agree, this is minor. But you know, the kernel is already complicated
> too much, we should try to simplify/cleanup everything we can ;)
>
>> Of the existing uses several of them sleep, which unfortunately means we
>> can not use rcu locking for everything.  The network namespace ones wind
>> up taking a reference to struct net because the have the legacy pid case
>> to deal with. Which makes we can not use fdget for all callers either.
>
> And that is why 1/1 adds proc_get_ns_by_fd/get_type which can also be used
> by the network namespace.
>
>> For this translate_pid rcu locking is sufficient, rcu locking is easy
>> and doing any more than rcu locking just seems silly.  So let me
>> respectfully suggest.
>>
>> struct ns_common *ns_by_fd_rcu(int fd, int type)
>> {
>> 	struct files_struct *files = current->files;
>> 	struct file *file;
>> 	struct ns_common *ns;
>> 	void *ret;
>>
>> 	file = fcheck_files(files, fd);
>>         if (!file)
>> 		return ERR_PTR(-EBADF);
>>
>> 	if (file->f_mode & FMODE_PATH)
>> 		return ERR_PTR(-EINVAL);
>>
>> 	if (file->f_op != &ns_file_operations)
>>         	return ERR_PTR(-EINVAL);
>>
>> 	ns = get_proc_ns(file_inode(file));
>> 	if (ns->ops->type != type)
>> 		return ERR_PTR(-EINVAL);
>>
>> 	return ns;
>> }
>
> OK, I won't insist, this too looks better to me than proc_ns_fdget(&fd_ref).
>
> And in any case fcheck_files() makes more sense than fdget(), somehow I did
> not think about this when I sent 1/1.
>
> Hmm. and after the quick look at cleanup_net() I can't understand whether
> get_net_ns_by_fd() can use ns_by_fd_rcu() + maybe_get_net(to_net_ns()) or
> not... Can it?

Some of those places need a reference that allows them to sleep, and the
code is shared with the legacy pid case so with an addition of get_net
we can use ns_by_fd_rcu().   There are cases like setns that could
use ns_by_fd_rcu() with code reording.

We can implement get_net_ns_by_fd as:
struct net *get_net_ns_by_fd(int fd)
{
        struct net *net;

	rcu_read_lock();
	net = net_ns_by_fd_rcu(fd);
        if (!IS_ERR(net))
        	get_net(net);
        rcu_read_unlock();

	return net;
}

Which means we can achieve code sharing with the pure rcu version
as a base.

If the networking code did not have the legacy pid case to handle I
would want to do something with struct fd, as the file descriptor
already keeps the struct net reference alive and struct fd allows
for sleeping.

Eric


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S965336AbbI2SmD (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Sep 2015 14:42:03 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36754 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S964820AbbI2Slo (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Sep 2015 14:41:44 -0400
Date: Tue, 29 Sep 2015 20:38:33 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
        linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?iso-8859-1?Q?St=E9phane?= Graber <stgraber@ubuntu.com>
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
Message-ID: <20150929183833.GA21875@redhat.com>
References: <20150925135246.27620.97496.stgit@buzz> <20150925175654.GA12504@redhat.com> <871tdi8pqj.fsf@x220.int.ebiederm.org> <20150929164315.GA16734@redhat.com> <874mid16bk.fsf@x220.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <874mid16bk.fsf@x220.int.ebiederm.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/29, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > OK, I won't insist, this too looks better to me than proc_ns_fdget(&fd_ref).
> >
> > And in any case fcheck_files() makes more sense than fdget(), somehow I did
> > not think about this when I sent 1/1.
> >
> > Hmm. and after the quick look at cleanup_net() I can't understand whether
> > get_net_ns_by_fd() can use ns_by_fd_rcu() + maybe_get_net(to_net_ns()) or
> > not... Can it?
>
> Some of those places need a reference that allows them to sleep, and the
> code is shared with the legacy pid case so with an addition of get_net
> we can use ns_by_fd_rcu().   There are cases like setns that could
> use ns_by_fd_rcu() with code reording.
>
> We can implement get_net_ns_by_fd as:
> struct net *get_net_ns_by_fd(int fd)
> {
>         struct net *net;
>
> 	rcu_read_lock();
> 	net = net_ns_by_fd_rcu(fd);
>         if (!IS_ERR(net))
>         	get_net(net);
>         rcu_read_unlock();
>
> 	return net;
> }
>
> Which means we can achieve code sharing with the pure rcu version
> as a base.

Yes, this is what I meant... but don't we need maybe_get_net() ?

Oleg.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S965299AbbI2TNO (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Sep 2015 15:13:14 -0400
Received: from out03.mta.xmission.com ([166.70.13.233]:36480 "EHLO
	out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S964956AbbI2TNI (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Sep 2015 15:13:08 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
        linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?utf-8?Q?St=C3=A9phane?= Graber <stgraber@ubuntu.com>
References: <20150925135246.27620.97496.stgit@buzz>
	<20150925175654.GA12504@redhat.com>
	<871tdi8pqj.fsf@x220.int.ebiederm.org>
	<20150929164315.GA16734@redhat.com>
	<874mid16bk.fsf@x220.int.ebiederm.org>
	<20150929183833.GA21875@redhat.com>
Date: Tue, 29 Sep 2015 14:05:42 -0500
In-Reply-To: <20150929183833.GA21875@redhat.com> (Oleg Nesterov's message of
	"Tue, 29 Sep 2015 20:38:33 +0200")
Message-ID: <87si5xxczd.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-XM-AID: U2FsdGVkX1/k8HJZJJbXyraaMT3YS1TUI9jjdCuFcn4=
X-SA-Exim-Connect-IP: 67.3.201.231
X-SA-Exim-Mail-From: ebiederm@xmission.com
X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	*  0.0 TVD_RCVD_IP Message was received from an IP address
	*  0.5 XMGappySubj_01 Very gappy subject
	*  1.0 XMGappySubj_02 Gappier still
	*  1.5 XMNoVowels Alpha-numberic number with no vowels
	*  0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.
	*  0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	*      [score: 0.4953]
	* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC
	*      [sa06 1397; Body=1 Fuz1=1 Fuz2=1]
	*  0.0 T_TooManySym_02 5+ unique symbols in subject
	*  0.0 T_TooManySym_01 4+ unique symbols in subject
	*  0.0 T_TooManySym_03 6+ unique symbols in subject
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: **;Oleg Nesterov <oleg@redhat.com>
X-Spam-Relay-Country: 
X-Spam-Timing: total 281 ms - load_scoreonly_sql: 0.05 (0.0%),
	signal_user_changed: 4.1 (1.5%), b_tie_ro: 2.9 (1.0%), parse: 1.40 (0.5%),
	extract_message_metadata: 4.8 (1.7%), get_uri_detail_list: 2.2 (0.8%),
	tests_pri_-1000: 4.3 (1.5%), tests_pri_-950: 1.43 (0.5%), tests_pri_-900:
	1.19 (0.4%), tests_pri_-400: 22 (7.9%), check_bayes: 21 (7.5%), b_tokenize: 6
	(2.2%), b_tok_get_all: 7 (2.6%), b_comp_prob: 2.2 (0.8%), b_tok_touch_all:
	2.7 (1.0%), b_finish: 0.75 (0.3%), tests_pri_0: 226 (80.2%), tests_pri_500:
	4.2 (1.5%), rewrite_mail: 0.00 (0.0%)
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
X-Spam-Flag: No
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Oleg Nesterov <oleg@redhat.com> writes:

> On 09/29, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <oleg@redhat.com> writes:
>>
>> > OK, I won't insist, this too looks better to me than proc_ns_fdget(&fd_ref).
>> >
>> > And in any case fcheck_files() makes more sense than fdget(), somehow I did
>> > not think about this when I sent 1/1.
>> >
>> > Hmm. and after the quick look at cleanup_net() I can't understand whether
>> > get_net_ns_by_fd() can use ns_by_fd_rcu() + maybe_get_net(to_net_ns()) or
>> > not... Can it?
>>
>> Some of those places need a reference that allows them to sleep, and the
>> code is shared with the legacy pid case so with an addition of get_net
>> we can use ns_by_fd_rcu().   There are cases like setns that could
>> use ns_by_fd_rcu() with code reording.
>>
>> We can implement get_net_ns_by_fd as:
>> struct net *get_net_ns_by_fd(int fd)
>> {
>>         struct net *net;
>>
>> 	rcu_read_lock();
>> 	net = net_ns_by_fd_rcu(fd);
>>         if (!IS_ERR(net))
>>         	get_net(net);
>>         rcu_read_unlock();
>>
>> 	return net;
>> }
>>
>> Which means we can achieve code sharing with the pure rcu version
>> as a base.
>
> Yes, this is what I meant... but don't we need maybe_get_net() ?

Let me see.

The call chain is a little interesting so let's trace it.

thread1                               thread2
  net = net_ns_by_fd_rcu(fd);           fput(file)
  get_net(net);                           ____fput
                                            __fput
                                              dput
                                                dentry_kill
                                                  __dentry_kill
                                                    dentry_iput
                                                      iput
                                                        iput_final
                                                          evict
                                                            ->evict_inode (nsfs_evict)
                                                              netns_put
                                                                 put_net
                                                                   __put_net
                                                                      queue_work(net_cleanup_work)
                                                                      ...
                                                                      cleanup_net
                                                                        synchronize_rcu.


Given that someone in another thread can put the file descriptor and I
don't see anything explicitly waiting until after the rcu critical
section ends to put the network namespace I guess we do need
maybe_get_net.

In practice I think the delay logic in fput will act as an rcu barrier,
but that is not guaranteed so we had better not count on it.  Sigh.

Anyway this is a long ways from a syscall to translate pids.

Eric


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753244AbbI3C7g (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Sep 2015 22:59:36 -0400
Received: from cn.fujitsu.com ([59.151.112.132]:18694 "EHLO
	heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org
	with ESMTP id S1752231AbbI3C7c (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Sep 2015 22:59:32 -0400
X-IronPort-AV: E=Sophos;i="5.15,520,1432569600"; 
   d="scan'208";a="101237401"
Message-ID: <560B4EC9.9060801@cn.fujitsu.com>
Date: Wed, 30 Sep 2015 10:54:01 +0800
From: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Eric W. Biederman" <ebiederm@xmission.com>,
        Oleg Nesterov <oleg@redhat.com>
CC: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
        <linux-api@vger.kernel.org>, <containers@lists.linux-foundation.org>,
        <linux-kernel@vger.kernel.org>, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?windows-1252?Q?St=E9phane_Graber?= <stgraber@ubuntu.com>
Subject: Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()
References: <20150925135246.27620.97496.stgit@buzz>	<20150925175654.GA12504@redhat.com> <871tdi8pqj.fsf@x220.int.ebiederm.org>
In-Reply-To: <871tdi8pqj.fsf@x220.int.ebiederm.org>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.167.226.78]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 09/29/2015 12:37 AM, Eric W. Biederman wrote:
> Oleg Nesterov <oleg@redhat.com> writes:
>
>> On 09/25, Konstantin Khlebnikov wrote:
>>> +struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref)
>>>   {
>>> -	struct file *file;
>>> +	struct ns_common *ns;
>>> +	struct fd f;
>>>   
>>> -	file = fget(fd);
>>> -	if (!file)
>>> +	f = fdget(fd);
>>> +	if (!f.file)
>>>   		return ERR_PTR(-EBADF);
>>>   
>>> -	if (file->f_op != &ns_file_operations)
>>> +	if (f.file->f_op != &ns_file_operations)
>>> +		goto out_invalid;
>>> +
>>> +	ns = get_proc_ns(file_inode(f.file));
>>> +	if (nstype && (ns->ops->type != nstype))
>>>   		goto out_invalid;
>>>   
>>> -	return file;
>>> +	*fd_ref = f;
>>> +	return ns;
>>>   
>>>   out_invalid:
>>> -	fput(file);
>>> +	fdput(f);
>>>   	return ERR_PTR(-EINVAL);
>>>   }
>> Well yes, fdget() makes sense but this is minor.
>>
>> Honestly, I do not really like the new helper... I understand this
>> is subjective, so I won't insist. But how about 1/1? We do not need
>> fd/file at all. With this patch your sys_getvpid() can just use
>> proc_get_ns_by_fd(fd, CLONE_NEWPID) and put_pid_ns().
>>
>> Eric, what do you think?
> At some level I don't care this is not exposed to userspace.
>
> However since we are going several rounds with this.
>
> Of the existing uses several of them sleep, which unfortunately means we
> can not use rcu locking for everything.  The network namespace ones wind
> up taking a reference to struct net because the have the legacy pid case
> to deal with.  Which makes we can not use fdget for all callers either.
>
> For this translate_pid rcu locking is sufficient, rcu locking is easy
> and doing any more than rcu locking just seems silly.  So let me
> respectfully suggest.
>
> struct ns_common *ns_by_fd_rcu(int fd, int type)
> {
> 	struct files_struct *files = current->files;
> 	struct file *file;
> 	struct ns_common *ns;
> 	void *ret;
pointer files seems no more useful. we can
use fcheck(fd) instead.

Thanks,

>
> 	file = fcheck_files(files, fd);
>          if (!file)
> 		return ERR_PTR(-EBADF);
>
> 	if (file->f_mode & FMODE_PATH)
> 		return ERR_PTR(-EINVAL);
>
> 	if (file->f_op != &ns_file_operations)
>          	return ERR_PTR(-EINVAL);
>
> 	ns = get_proc_ns(file_inode(file));
> 	if (ns->ops->type != type)
> 		return ERR_PTR(-EINVAL);
>
> 	return ns;
> }
>
> struct pid_namespace *pidns_by_fd_rcu(int fd)
> {
> 	struct ns_common *ns = ns_by_fd_rcu(fd, CLONE_NEWPID);
>          if (IS_ERR(ns))
> 		return ERR_CAST(ns);
> 	return container_of(ns, struct pid_namespace, ns);
> }
>
> SYSCALL_DEFINE3(translate_pid, pid_t, pid_nr, int, sourcefd, int, targetfd)
> {
> 	struct pid_namespace *source, *target;
> 	struct pid *pid;
> 	pid_t result;
>
> 	rcu_read_lock();
>
> 	if (sourcefd >= 0)
>          	source = pidns_by_fd_rcu(sourcefd);
> 	else
> 		source = task_active_pid_ns(current);
>
> 	if (targetfd >= 0)
>          	target = pidns_by_fd_rcu(targetfd);
> 	else
> 		target = task_active_pid_ns(current);
>
> 	pid = find_pid_ns(pid_nr, source);
>          result = pid_nr_ns(pid, target);
>          if (result == 0)
> 		result = -ESRCH;
>
> 	rcu_read_unlock();
>
> 	return result;
> }
>
> Eric
> .
>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753782AbbJTKEf (ORCPT <rfc822;w@1wt.eu>);
	Tue, 20 Oct 2015 06:04:35 -0400
Received: from forward-corp1g.mail.yandex.net ([95.108.253.251]:43512 "EHLO
	forward-corp1g.mail.yandex.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752525AbbJTKE3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 20 Oct 2015 06:04:29 -0400
Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru
Subject: Re: [PATCH RFC v3 2/2] pidns: introduce syscall getvpid
To: "Eric W. Biederman" <ebiederm@xmission.com>
References: <20150925135246.27620.97496.stgit@buzz>
 <20150925135247.27620.37109.stgit@buzz>
 <87d1x25vng.fsf@x220.int.ebiederm.org>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Oleg Nesterov <oleg@redhat.com>,
        Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?UTF-8?Q?St=c3=a9phane_Graber?= <stgraber@ubuntu.com>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Message-ID: <562611A7.7070606@yandex-team.ru>
Date: Tue, 20 Oct 2015 13:04:23 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <87d1x25vng.fsf@x220.int.ebiederm.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 28.09.2015 19:57, Eric W. Biederman wrote:
> Konstantin Khlebnikov <khlebnikov@yandex-team.ru> writes:
>
>> If pid is negative then getvpid() returns pid of parent task for -pid.
>
> Now that I am noticing this.  I don't think I have seen any discussion
> about justifying a syscall getting another processes parent pid.  My
> apologies if I just missed it.
>

Sorry for late response. This completely fell out of my mind after LinuxCon.

> Why do we want the the parent pid?  We can we usefully do with it?
> Is proc really that bad of an interface?
>
> Fetching a parent pid feels like a separate logical operation
> from pid translation.  Which makes me a bit uneasy about this
> part of the conversation.

Yep proc interface is bad. /proc/$pid/stat is almost impossible to
parse without flaws because task could set second field "comm" into
any string and fake ppid  - for example ") Z 1". /proc/$pid/status
is better but it has more information and thus slower.

This trick for distant getppid looks cheap useful:
in this interface space of negative pids is free for use.

>
>> Examples:
>> getvpid(pid, ns, -1)      - get pid in our pid namespace
>> getvpid(pid, -1, ns)      - get pid in container
>> getvpid(pid, -1, ns) > 0  - is pid is reachable from container?
>> getvpid(1, ns1, ns2) > 0  - is ns1 inside ns2?
>> getvpid(1, ns1, ns2) == 0 - is ns1 outside ns2?
>> getvpid(1, ns, -1)        - get init task of pid-namespace
>> getvpid(-1, ns, -1)       - get reaper of init task in parent pid-namespace
>> getvpid(-pid, -1, -1)     - get ppid by pid
>
> As I step back and pay attention to this case I am half wondering if
> perhaps what would be most useful is a file descriptor that refers
> to a pid and an updated set of system calls that takes pid file
> descriptors instead of pids.

Fd which pins pids isn't a good idea.

I think it's better to refer (but not hold) task rather than pid.
For example inode of taskfd will hold small buffer for task exit
status: task holds reference to its own taskfd inode and populates
status when exits. Here will be no zombies and delayed reaping.

Something like:

task_fd = clonefd()
                      ...
select(...)
                      exit(...)
pread(task_fd, &status_rusage_etc, sizeof, 0);
close(task_fd);

Task pid also could be part of structure in that fd. Potentially it
could provide the same information as /proc/$pid/... in effective
binary format: we can read only required fields of structure and
kernel can skip unneeded calculations.

>
> Something like:
>
>      getpidfd(int pidnsfd, pid_t pid);
>
>      waitfd(int pidfd, int *status, int options, struct rusage *rusage);
>
>      killfd(int pidfd, int sig);
>
>      clonefd(...);
>
> And perhaps:
>      pid_nr_ns(int pidnsfd, int pidfd);
>
>      parentfd(int pidfd);
>
> Eric
>

-- 
Konstantin

