* [PATCH 1/2] ns: Allow ns_entries to have custom symlink content @ 2017-01-14 14:14 Kirill Tkhai 2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai 2017-01-16 8:18 ` [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Cyrill Gorcunov 0 siblings, 2 replies; 10+ messages in thread From: Kirill Tkhai @ 2017-01-14 14:14 UTC (permalink / raw) To: avagin, linux-kernel, linux-fsdevel, ktkhai, ebiederm, gorcunov, viro Make possible to have link content prefix yyy different from the link name xxx: $ readlink /proc/[pid]/ns/xxx yyy:[4026531838] This will be used in next patch. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> --- fs/nsfs.c | 4 +++- include/linux/proc_ns.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/nsfs.c b/fs/nsfs.c index 8c9fb29c6673..c2499c59bf51 100644 --- a/fs/nsfs.c +++ b/fs/nsfs.c @@ -182,9 +182,11 @@ int ns_get_name(char *buf, size_t size, struct task_struct *task, { struct ns_common *ns; int res = -ENOENT; + const char *name; ns = ns_ops->get(task); if (ns) { - res = snprintf(buf, size, "%s:[%u]", ns_ops->name, ns->inum); + name = ns_ops->real_ns_name ? : ns_ops->name; + res = snprintf(buf, size, "%s:[%u]", name, ns->inum); ns_ops->put(ns); } return res; diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h index 12cb8bd81d2d..88dba3b53375 100644 --- a/include/linux/proc_ns.h +++ b/include/linux/proc_ns.h @@ -14,6 +14,7 @@ struct inode; struct proc_ns_operations { const char *name; + const char *real_ns_name; int type; struct ns_common *(*get)(struct task_struct *task); void (*put)(struct ns_common *ns); ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace 2017-01-14 14:14 [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Kirill Tkhai @ 2017-01-14 14:15 ` Kirill Tkhai 2017-01-17 20:00 ` Andrei Vagin ` (2 more replies) 2017-01-16 8:18 ` [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Cyrill Gorcunov 1 sibling, 3 replies; 10+ messages in thread From: Kirill Tkhai @ 2017-01-14 14:15 UTC (permalink / raw) To: avagin, linux-kernel, linux-fsdevel, ktkhai, ebiederm, gorcunov, viro For correct checkpointing/restoring of a task from userspace it's need to know the task's pid_ns_for_children. Currently, there is no a sane way to do that (the only possible trick is to force the task create a new child and to analize the child's /proc/[pid]/ns/pid link, that is performance-stupid). The patch exposes pid_ns_for_children to ns directory in standard way with the name "pid_for_children": ~# ls /proc/5531/ns -l | grep pid lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> --- fs/proc/namespaces.c | 1 + include/linux/proc_ns.h | 1 + kernel/pid_namespace.c | 25 +++++++++++++++++++++++++ 3 files changed, 27 insertions(+) diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c index 766f0c637ad1..3803b24ca220 100644 --- a/fs/proc/namespaces.c +++ b/fs/proc/namespaces.c @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = { #endif #ifdef CONFIG_PID_NS &pidns_operations, + &pidns_for_children_operations, #endif #ifdef CONFIG_USER_NS &userns_operations, diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h index 88dba3b53375..58ab28d81fc2 100644 --- a/include/linux/proc_ns.h +++ b/include/linux/proc_ns.h @@ -27,6 +27,7 @@ extern const struct proc_ns_operations netns_operations; extern const struct proc_ns_operations utsns_operations; extern const struct proc_ns_operations ipcns_operations; extern const struct proc_ns_operations pidns_operations; +extern const struct proc_ns_operations pidns_for_children_operations; extern const struct proc_ns_operations userns_operations; extern const struct proc_ns_operations mntns_operations; extern const struct proc_ns_operations cgroupns_operations; diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c index df9e8e9e0be7..cbe950d4a11e 100644 --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -369,6 +369,20 @@ static struct ns_common *pidns_get(struct task_struct *task) return ns ? &ns->ns : NULL; } +static struct ns_common *pidns_for_children_get(struct task_struct *task) +{ + struct pid_namespace *ns = NULL; + + task_lock(task); + if (task->nsproxy) { + ns = task->nsproxy->pid_ns_for_children; + get_pid_ns(ns); + } + task_unlock(task); + + return ns ? &ns->ns : NULL; +} + static void pidns_put(struct ns_common *ns) { put_pid_ns(to_pid_ns(ns)); @@ -438,6 +452,17 @@ const struct proc_ns_operations pidns_operations = { .get_parent = pidns_get_parent, }; +const struct proc_ns_operations pidns_for_children_operations = { + .name = "pid_for_children", + .real_ns_name = "pid", + .type = CLONE_NEWPID, + .get = pidns_for_children_get, + .put = pidns_put, + .install = pidns_install, + .owner = pidns_owner, + .get_parent = pidns_get_parent, +}; + static __init int pid_namespaces_init(void) { pid_ns_cachep = KMEM_CACHE(pid_namespace, SLAB_PANIC); ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace 2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai @ 2017-01-17 20:00 ` Andrei Vagin [not found] ` <148440329770.30622.16593902895676160550.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-01-30 15:10 ` Kirill Tkhai 2 siblings, 0 replies; 10+ messages in thread From: Andrei Vagin @ 2017-01-17 20:00 UTC (permalink / raw) To: Kirill Tkhai Cc: avagin, linux-kernel, linux-fsdevel, ebiederm, gorcunov, viro, linux-api, Michael Kerrisk On Sat, Jan 14, 2017 at 05:15:04PM +0300, Kirill Tkhai wrote: > For correct checkpointing/restoring of a task from userspace > it's need to know the task's pid_ns_for_children. Currently, > there is no a sane way to do that (the only possible trick > is to force the task create a new child and to analize the > child's /proc/[pid]/ns/pid link, that is performance-stupid). > > The patch exposes pid_ns_for_children to ns directory > in standard way with the name "pid_for_children": > > ~# ls /proc/5531/ns -l | grep pid > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] > Cc: linux-api, Michael Kerrisk Acked-by: Andrei Vagin <avagin@virtuozzo.com> > Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> > --- > fs/proc/namespaces.c | 1 + > include/linux/proc_ns.h | 1 + > kernel/pid_namespace.c | 25 +++++++++++++++++++++++++ > 3 files changed, 27 insertions(+) > > diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c > index 766f0c637ad1..3803b24ca220 100644 > --- a/fs/proc/namespaces.c > +++ b/fs/proc/namespaces.c > @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = { > #endif > #ifdef CONFIG_PID_NS > &pidns_operations, > + &pidns_for_children_operations, > #endif > #ifdef CONFIG_USER_NS > &userns_operations, > diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h > index 88dba3b53375..58ab28d81fc2 100644 > --- a/include/linux/proc_ns.h > +++ b/include/linux/proc_ns.h > @@ -27,6 +27,7 @@ extern const struct proc_ns_operations netns_operations; > extern const struct proc_ns_operations utsns_operations; > extern const struct proc_ns_operations ipcns_operations; > extern const struct proc_ns_operations pidns_operations; > +extern const struct proc_ns_operations pidns_for_children_operations; > extern const struct proc_ns_operations userns_operations; > extern const struct proc_ns_operations mntns_operations; > extern const struct proc_ns_operations cgroupns_operations; > diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c > index df9e8e9e0be7..cbe950d4a11e 100644 > --- a/kernel/pid_namespace.c > +++ b/kernel/pid_namespace.c > @@ -369,6 +369,20 @@ static struct ns_common *pidns_get(struct task_struct *task) > return ns ? &ns->ns : NULL; > } > > +static struct ns_common *pidns_for_children_get(struct task_struct *task) > +{ > + struct pid_namespace *ns = NULL; > + > + task_lock(task); > + if (task->nsproxy) { > + ns = task->nsproxy->pid_ns_for_children; > + get_pid_ns(ns); > + } > + task_unlock(task); > + > + return ns ? &ns->ns : NULL; > +} > + > static void pidns_put(struct ns_common *ns) > { > put_pid_ns(to_pid_ns(ns)); > @@ -438,6 +452,17 @@ const struct proc_ns_operations pidns_operations = { > .get_parent = pidns_get_parent, > }; > > +const struct proc_ns_operations pidns_for_children_operations = { > + .name = "pid_for_children", > + .real_ns_name = "pid", > + .type = CLONE_NEWPID, > + .get = pidns_for_children_get, > + .put = pidns_put, > + .install = pidns_install, > + .owner = pidns_owner, > + .get_parent = pidns_get_parent, > +}; > + > static __init int pid_namespaces_init(void) > { > pid_ns_cachep = KMEM_CACHE(pid_namespace, SLAB_PANIC); > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace @ 2017-01-17 20:00 ` Andrei Vagin 0 siblings, 0 replies; 10+ messages in thread From: Andrei Vagin @ 2017-01-17 20:00 UTC (permalink / raw) To: Kirill Tkhai Cc: avagin, linux-kernel, linux-fsdevel, ebiederm, gorcunov, viro, linux-api, Michael Kerrisk On Sat, Jan 14, 2017 at 05:15:04PM +0300, Kirill Tkhai wrote: > For correct checkpointing/restoring of a task from userspace > it's need to know the task's pid_ns_for_children. Currently, > there is no a sane way to do that (the only possible trick > is to force the task create a new child and to analize the > child's /proc/[pid]/ns/pid link, that is performance-stupid). > > The patch exposes pid_ns_for_children to ns directory > in standard way with the name "pid_for_children": > > ~# ls /proc/5531/ns -l | grep pid > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] > Cc: linux-api, Michael Kerrisk Acked-by: Andrei Vagin <avagin@virtuozzo.com> > Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> > --- > fs/proc/namespaces.c | 1 + > include/linux/proc_ns.h | 1 + > kernel/pid_namespace.c | 25 +++++++++++++++++++++++++ > 3 files changed, 27 insertions(+) > > diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c > index 766f0c637ad1..3803b24ca220 100644 > --- a/fs/proc/namespaces.c > +++ b/fs/proc/namespaces.c > @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = { > #endif > #ifdef CONFIG_PID_NS > &pidns_operations, > + &pidns_for_children_operations, > #endif > #ifdef CONFIG_USER_NS > &userns_operations, > diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h > index 88dba3b53375..58ab28d81fc2 100644 > --- a/include/linux/proc_ns.h > +++ b/include/linux/proc_ns.h > @@ -27,6 +27,7 @@ extern const struct proc_ns_operations netns_operations; > extern const struct proc_ns_operations utsns_operations; > extern const struct proc_ns_operations ipcns_operations; > extern const struct proc_ns_operations pidns_operations; > +extern const struct proc_ns_operations pidns_for_children_operations; > extern const struct proc_ns_operations userns_operations; > extern const struct proc_ns_operations mntns_operations; > extern const struct proc_ns_operations cgroupns_operations; > diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c > index df9e8e9e0be7..cbe950d4a11e 100644 > --- a/kernel/pid_namespace.c > +++ b/kernel/pid_namespace.c > @@ -369,6 +369,20 @@ static struct ns_common *pidns_get(struct task_struct *task) > return ns ? &ns->ns : NULL; > } > > +static struct ns_common *pidns_for_children_get(struct task_struct *task) > +{ > + struct pid_namespace *ns = NULL; > + > + task_lock(task); > + if (task->nsproxy) { > + ns = task->nsproxy->pid_ns_for_children; > + get_pid_ns(ns); > + } > + task_unlock(task); > + > + return ns ? &ns->ns : NULL; > +} > + > static void pidns_put(struct ns_common *ns) > { > put_pid_ns(to_pid_ns(ns)); > @@ -438,6 +452,17 @@ const struct proc_ns_operations pidns_operations = { > .get_parent = pidns_get_parent, > }; > > +const struct proc_ns_operations pidns_for_children_operations = { > + .name = "pid_for_children", > + .real_ns_name = "pid", > + .type = CLONE_NEWPID, > + .get = pidns_for_children_get, > + .put = pidns_put, > + .install = pidns_install, > + .owner = pidns_owner, > + .get_parent = pidns_get_parent, > +}; > + > static __init int pid_namespaces_init(void) > { > pid_ns_cachep = KMEM_CACHE(pid_namespace, SLAB_PANIC); > ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <148440329770.30622.16593902895676160550.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>]
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace 2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai @ 2017-01-23 21:49 ` Alban Crequy [not found] ` <148440329770.30622.16593902895676160550.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 2017-01-30 15:10 ` Kirill Tkhai 2 siblings, 0 replies; 10+ messages in thread From: Alban Crequy @ 2017-01-23 21:49 UTC (permalink / raw) To: Kirill Tkhai Cc: Andrey Vagin, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman, Cyrill Gorcunov, Alexander Viro, Michael Kerrisk-manpages, Linux API On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org> wrote: > For correct checkpointing/restoring of a task from userspace > it's need to know the task's pid_ns_for_children. Currently, > there is no a sane way to do that (the only possible trick > is to force the task create a new child and to analize the > child's /proc/[pid]/ns/pid link, that is performance-stupid). > > The patch exposes pid_ns_for_children to ns directory > in standard way with the name "pid_for_children": > > ~# ls /proc/5531/ns -l | grep pid > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] > > Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org> What's happening if a process, after unsharing CLONE_NEWPID, does not fork but instead let another process open the new "pid_for_children" and then setns()+fork()? Is that other process allowed to create the "pid 1" in the new pid namespaces? Is that also allowed if the other process lives in a sibling pid namespace? If so, that would break what pid_namespaces(7) says: "the parental relationship between processes mirrors the parental relationship between PID namespaces: the parent of a process is either in the same namespace or resides in the immediate parent PID namespace." ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace @ 2017-01-23 21:49 ` Alban Crequy 0 siblings, 0 replies; 10+ messages in thread From: Alban Crequy @ 2017-01-23 21:49 UTC (permalink / raw) To: Kirill Tkhai Cc: Andrey Vagin, linux-kernel@vger.kernel.org, linux-fsdevel, Eric W. Biederman, Cyrill Gorcunov, Alexander Viro, Michael Kerrisk-manpages, Linux API On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai@virtuozzo.com> wrote: > For correct checkpointing/restoring of a task from userspace > it's need to know the task's pid_ns_for_children. Currently, > there is no a sane way to do that (the only possible trick > is to force the task create a new child and to analize the > child's /proc/[pid]/ns/pid link, that is performance-stupid). > > The patch exposes pid_ns_for_children to ns directory > in standard way with the name "pid_for_children": > > ~# ls /proc/5531/ns -l | grep pid > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] > > Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> What's happening if a process, after unsharing CLONE_NEWPID, does not fork but instead let another process open the new "pid_for_children" and then setns()+fork()? Is that other process allowed to create the "pid 1" in the new pid namespaces? Is that also allowed if the other process lives in a sibling pid namespace? If so, that would break what pid_namespaces(7) says: "the parental relationship between processes mirrors the parental relationship between PID namespaces: the parent of a process is either in the same namespace or resides in the immediate parent PID namespace." ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace 2017-01-23 21:49 ` Alban Crequy @ 2017-01-24 8:35 ` Kirill Tkhai -1 siblings, 0 replies; 10+ messages in thread From: Kirill Tkhai @ 2017-01-24 8:35 UTC (permalink / raw) To: Alban Crequy Cc: Andrey Vagin, linux-kernel@vger.kernel.org, linux-fsdevel, Eric W. Biederman, Cyrill Gorcunov, Alexander Viro, Michael Kerrisk-manpages, Linux API On 24.01.2017 00:49, Alban Crequy wrote: > On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai@virtuozzo.com> wrote: >> For correct checkpointing/restoring of a task from userspace >> it's need to know the task's pid_ns_for_children. Currently, >> there is no a sane way to do that (the only possible trick >> is to force the task create a new child and to analize the >> child's /proc/[pid]/ns/pid link, that is performance-stupid). >> >> The patch exposes pid_ns_for_children to ns directory >> in standard way with the name "pid_for_children": >> >> ~# ls /proc/5531/ns -l | grep pid >> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] >> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] >> >> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> > > What's happening if a process, after unsharing CLONE_NEWPID, does not > fork but instead let another process open the new "pid_for_children" > and then setns()+fork()? Is that other process allowed to create the > "pid 1" in the new pid namespaces? Is that also allowed if the other > process lives in a sibling pid namespace? If so, that would break what > pid_namespaces(7) says: > > "the parental relationship between processes mirrors the parental > relationship between PID namespaces: the parent of a process is > either in the same namespace or resides in the immediate parent > PID namespace." > You can setns() on a pid_ns only if your active pid_ns is a (grand)parent for the target pid_ns. So, the situation you described is not possible. See pidns_install() for the details. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace @ 2017-01-24 8:35 ` Kirill Tkhai 0 siblings, 0 replies; 10+ messages in thread From: Kirill Tkhai @ 2017-01-24 8:35 UTC (permalink / raw) To: Alban Crequy Cc: Andrey Vagin, linux-kernel@vger.kernel.org, linux-fsdevel, Eric W. Biederman, Cyrill Gorcunov, Alexander Viro, Michael Kerrisk-manpages, Linux API On 24.01.2017 00:49, Alban Crequy wrote: > On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai@virtuozzo.com> wrote: >> For correct checkpointing/restoring of a task from userspace >> it's need to know the task's pid_ns_for_children. Currently, >> there is no a sane way to do that (the only possible trick >> is to force the task create a new child and to analize the >> child's /proc/[pid]/ns/pid link, that is performance-stupid). >> >> The patch exposes pid_ns_for_children to ns directory >> in standard way with the name "pid_for_children": >> >> ~# ls /proc/5531/ns -l | grep pid >> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] >> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] >> >> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> > > What's happening if a process, after unsharing CLONE_NEWPID, does not > fork but instead let another process open the new "pid_for_children" > and then setns()+fork()? Is that other process allowed to create the > "pid 1" in the new pid namespaces? Is that also allowed if the other > process lives in a sibling pid namespace? If so, that would break what > pid_namespaces(7) says: > > "the parental relationship between processes mirrors the parental > relationship between PID namespaces: the parent of a process is > either in the same namespace or resides in the immediate parent > PID namespace." > You can setns() on a pid_ns only if your active pid_ns is a (grand)parent for the target pid_ns. So, the situation you described is not possible. See pidns_install() for the details. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace 2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai 2017-01-17 20:00 ` Andrei Vagin [not found] ` <148440329770.30622.16593902895676160550.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> @ 2017-01-30 15:10 ` Kirill Tkhai 2 siblings, 0 replies; 10+ messages in thread From: Kirill Tkhai @ 2017-01-30 15:10 UTC (permalink / raw) To: avagin, linux-kernel, linux-fsdevel, ebiederm, gorcunov, viro ping On 14.01.2017 17:15, Kirill Tkhai wrote: > For correct checkpointing/restoring of a task from userspace > it's need to know the task's pid_ns_for_children. Currently, > there is no a sane way to do that (the only possible trick > is to force the task create a new child and to analize the > child's /proc/[pid]/ns/pid link, that is performance-stupid). > > The patch exposes pid_ns_for_children to ns directory > in standard way with the name "pid_for_children": > > ~# ls /proc/5531/ns -l | grep pid > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836] > lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286] > > Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> > --- > fs/proc/namespaces.c | 1 + > include/linux/proc_ns.h | 1 + > kernel/pid_namespace.c | 25 +++++++++++++++++++++++++ > 3 files changed, 27 insertions(+) > > diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c > index 766f0c637ad1..3803b24ca220 100644 > --- a/fs/proc/namespaces.c > +++ b/fs/proc/namespaces.c > @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = { > #endif > #ifdef CONFIG_PID_NS > &pidns_operations, > + &pidns_for_children_operations, > #endif > #ifdef CONFIG_USER_NS > &userns_operations, > diff --git a/include/linux/proc_ns.h b/include/linux/proc_ns.h > index 88dba3b53375..58ab28d81fc2 100644 > --- a/include/linux/proc_ns.h > +++ b/include/linux/proc_ns.h > @@ -27,6 +27,7 @@ extern const struct proc_ns_operations netns_operations; > extern const struct proc_ns_operations utsns_operations; > extern const struct proc_ns_operations ipcns_operations; > extern const struct proc_ns_operations pidns_operations; > +extern const struct proc_ns_operations pidns_for_children_operations; > extern const struct proc_ns_operations userns_operations; > extern const struct proc_ns_operations mntns_operations; > extern const struct proc_ns_operations cgroupns_operations; > diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c > index df9e8e9e0be7..cbe950d4a11e 100644 > --- a/kernel/pid_namespace.c > +++ b/kernel/pid_namespace.c > @@ -369,6 +369,20 @@ static struct ns_common *pidns_get(struct task_struct *task) > return ns ? &ns->ns : NULL; > } > > +static struct ns_common *pidns_for_children_get(struct task_struct *task) > +{ > + struct pid_namespace *ns = NULL; > + > + task_lock(task); > + if (task->nsproxy) { > + ns = task->nsproxy->pid_ns_for_children; > + get_pid_ns(ns); > + } > + task_unlock(task); > + > + return ns ? &ns->ns : NULL; > +} > + > static void pidns_put(struct ns_common *ns) > { > put_pid_ns(to_pid_ns(ns)); > @@ -438,6 +452,17 @@ const struct proc_ns_operations pidns_operations = { > .get_parent = pidns_get_parent, > }; > > +const struct proc_ns_operations pidns_for_children_operations = { > + .name = "pid_for_children", > + .real_ns_name = "pid", > + .type = CLONE_NEWPID, > + .get = pidns_for_children_get, > + .put = pidns_put, > + .install = pidns_install, > + .owner = pidns_owner, > + .get_parent = pidns_get_parent, > +}; > + > static __init int pid_namespaces_init(void) > { > pid_ns_cachep = KMEM_CACHE(pid_namespace, SLAB_PANIC); > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] ns: Allow ns_entries to have custom symlink content 2017-01-14 14:14 [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Kirill Tkhai 2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai @ 2017-01-16 8:18 ` Cyrill Gorcunov 1 sibling, 0 replies; 10+ messages in thread From: Cyrill Gorcunov @ 2017-01-16 8:18 UTC (permalink / raw) To: Kirill Tkhai; +Cc: avagin, linux-kernel, linux-fsdevel, ebiederm, viro On Sat, Jan 14, 2017 at 05:14:48PM +0300, Kirill Tkhai wrote: > Make possible to have link content prefix yyy > different from the link name xxx: > > $ readlink /proc/[pid]/ns/xxx > yyy:[4026531838] > > This will be used in next patch. > > Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> I don't like much @real_ns_name variable naming, but it's just personal opinion. The rest looks good to me (for both patches). If only I didn't miss something obvious. Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-01-30 15:10 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-14 14:14 [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Kirill Tkhai
2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai
2017-01-17 20:00 ` Andrei Vagin
2017-01-17 20:00 ` Andrei Vagin
[not found] ` <148440329770.30622.16593902895676160550.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2017-01-23 21:49 ` Alban Crequy
2017-01-23 21:49 ` Alban Crequy
2017-01-24 8:35 ` Kirill Tkhai
2017-01-24 8:35 ` Kirill Tkhai
2017-01-30 15:10 ` Kirill Tkhai
2017-01-16 8:18 ` [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Cyrill Gorcunov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.