[RFC PATCH 0/3] ns,procfs: pid conversion between ns and showing pidns hierarchy

[RFC PATCH 0/3] ns,procfs: pid conversion between ns and showing pidns hierarchy

[Chen Hanxiao]

This series will expose pid inside containers
via procfs.
Also show the hierarchy of pid namespcae.
Then we could know how pid looks inside a container
and their ns relationships.

Chen Hanxiao (3):
  procfs: check uniq proc_dir_entry subdir name
  procfs: show hierarchy of pid namespace
  /proc/pid/status: show all sets of pid according to ns

 fs/proc/Kconfig           |   6 ++
 fs/proc/Makefile          |   1 +
 fs/proc/array.c           |  17 +++++
 fs/proc/generic.c         |  15 +++++
 fs/proc/pidns_hierarchy.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/proc_fs.h   |   3 +
 6 files changed, 203 insertions(+)
 create mode 100644 fs/proc/pidns_hierarchy.c

-- 
1.9.0

[RFC PATCH 1/3] procfs: check uniq proc_dir_entry subdir name

[Chen Hanxiao]

Check whether a proc dir has a subdir
with a specific name.
Will be used in a later patch.

Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
---
 fs/proc/generic.c       | 15 +++++++++++++++
 include/linux/proc_fs.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index b7f268e..4d576c2 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -173,6 +173,21 @@ static const struct inode_operations proc_link_inode_operations = {
 	.follow_link	= proc_follow_link,
 };
 
+/* check whether dir has @name member */
+struct proc_dir_entry *proc_uniq_dir(struct proc_dir_entry *de, char *name)
+{
+	spin_lock(&proc_subdir_lock);
+	for (de = de->subdir; de ; de = de->next) {
+		if (!strcmp(de->name, name)) {
+			spin_unlock(&proc_subdir_lock);
+			return de;
+		}
+	}
+	spin_unlock(&proc_subdir_lock);
+	return NULL;
+}
+EXPORT_SYMBOL(proc_uniq_dir);
+
 /*
  * Don't create negative dentries here, return -ENOENT by hand
  * instead.
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 9d117f6..38e87aa 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -41,6 +41,7 @@ extern void *proc_get_parent_data(const struct inode *);
 extern void proc_remove(struct proc_dir_entry *);
 extern void remove_proc_entry(const char *, struct proc_dir_entry *);
 extern int remove_proc_subtree(const char *, struct proc_dir_entry *);
+extern struct proc_dir_entry *proc_uniq_dir(struct proc_dir_entry *, char *);
 
 #else /* CONFIG_PROC_FS */
 
@@ -71,6 +72,8 @@ static inline void *proc_get_parent_data(const struct inode *inode) { BUG(); ret
 static inline void proc_remove(struct proc_dir_entry *de) {}
 #define remove_proc_entry(name, parent) do {} while (0)
 static inline int remove_proc_subtree(const char *name, struct proc_dir_entry *parent) { return 0; }
+static inline struct proc_dir_entry *proc_uniq_dir(struct proc_dir_entry *,
+	char *) {return 0; }
 
 #endif /* CONFIG_PROC_FS */
 
-- 
1.9.0

Re: [RFC PATCH 1/3] procfs: check uniq proc_dir_entry subdir name

[Serge E. Hallyn]

Quoting Chen Hanxiao (chenhanxiao@cn.fujitsu.com):
> Check whether a proc dir has a subdir
> with a specific name.
> Will be used in a later patch.
> 
> Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
> ---
>  fs/proc/generic.c       | 15 +++++++++++++++
>  include/linux/proc_fs.h |  3 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/fs/proc/generic.c b/fs/proc/generic.c
> index b7f268e..4d576c2 100644
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -173,6 +173,21 @@ static const struct inode_operations proc_link_inode_operations = {
>  	.follow_link	= proc_follow_link,
>  };
>  
> +/* check whether dir has @name member */
> +struct proc_dir_entry *proc_uniq_dir(struct proc_dir_entry *de, char *name)
> +{
> +	spin_lock(&proc_subdir_lock);
> +	for (de = de->subdir; de ; de = de->next) {
> +		if (!strcmp(de->name, name)) {

Should you pde_get(de) here?

> +			spin_unlock(&proc_subdir_lock);
> +			return de;
> +		}
> +	}
> +	spin_unlock(&proc_subdir_lock);
> +	return NULL;
> +}
> +EXPORT_SYMBOL(proc_uniq_dir);
> +
>  /*
>   * Don't create negative dentries here, return -ENOENT by hand
>   * instead.
> diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
> index 9d117f6..38e87aa 100644
> --- a/include/linux/proc_fs.h
> +++ b/include/linux/proc_fs.h
> @@ -41,6 +41,7 @@ extern void *proc_get_parent_data(const struct inode *);
>  extern void proc_remove(struct proc_dir_entry *);
>  extern void remove_proc_entry(const char *, struct proc_dir_entry *);
>  extern int remove_proc_subtree(const char *, struct proc_dir_entry *);
> +extern struct proc_dir_entry *proc_uniq_dir(struct proc_dir_entry *, char *);
>  
>  #else /* CONFIG_PROC_FS */
>  
> @@ -71,6 +72,8 @@ static inline void *proc_get_parent_data(const struct inode *inode) { BUG(); ret
>  static inline void proc_remove(struct proc_dir_entry *de) {}
>  #define remove_proc_entry(name, parent) do {} while (0)
>  static inline int remove_proc_subtree(const char *name, struct proc_dir_entry *parent) { return 0; }
> +static inline struct proc_dir_entry *proc_uniq_dir(struct proc_dir_entry *,
> +	char *) {return 0; }
>  
>  #endif /* CONFIG_PROC_FS */
>  
> -- 
> 1.9.0
> 
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

[RFC PATCH 2/3] procfs: show hierarchy of pid namespace

[Chen Hanxiao]

This patch will show the hierarchy of pid namespace
under /proc/pidns like:
/proc/pidns
├── hierarchy
│   ├── pidns4026532399
│   │   ├── pidns -> /proc/2863/ns/pid
│   │   └── pidns4026532515
│   │       └── pidns -> /proc/10611/ns/pid
│   └── pidns4026532504
│       └── pidns -> /proc/4450/ns/pid
└── refresh

a) hierarchy dir:
  use to show hierarchy infomation using dir and symlinks.
  dirs are named as pidns($inum)
  a symlink is created under pidns($inum), and linked to
  that pid namespace.

b) refresh
  trigger key.
  We need to write sth to /proc/nspid/refresh,
  then we could get hierarchy info
  under /proc/pidns/hierarchy.

Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
---
 fs/proc/Kconfig           |   6 ++
 fs/proc/Makefile          |   1 +
 fs/proc/pidns_hierarchy.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 168 insertions(+)
 create mode 100644 fs/proc/pidns_hierarchy.c

diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..e2e2292 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
 	  /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
 	  /proc/kpagecount, and /proc/kpageflags. Disabling these
           interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+	bool "Enable /proc/pidns_hierarchy support" if EXPERT
+	depends on PROC_FS
+	help
+	  Show pid namespace hierarchy infomation
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 239493e..733599b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -29,3 +29,4 @@ proc-$(CONFIG_PROC_KCORE)	+= kcore.o
 proc-$(CONFIG_PROC_VMCORE)	+= vmcore.o
 proc-$(CONFIG_PRINTK)	+= kmsg.o
 proc-$(CONFIG_PROC_PAGE_MONITOR)	+= page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY)	+= pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 0000000..d35340f
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,161 @@
+/*
+ * proc_pidns_hierarchy.c -- handles pidns hierarchy
+ *
+ * Copyright 2014
+ */
+
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/proc_fs.h>
+#include <linux/module.h>
+#include <linux/list.h>
+#include <linux/slab.h>
+#include <linux/pid_namespace.h>
+
+/*
+ * The /proc/pidns directory
+ */
+
+#define BASE_DIR	"pidns"			/* Subdir in /proc */
+#define HIERARCHY_DIR	"pidns/hierarchy"	/* hierarchy dir */
+#define REFRESH_KEY	"pidns/refresh"		/* refresh key */
+#define NAME		"pidns_hierarchy"	/* Module name */
+
+static LIST_HEAD(pidns_list);
+static DEFINE_RWLOCK(pidns_lock);
+static struct proc_dir_entry *proc_root;
+
+struct ns_pid_list {
+	struct pid *pid;
+	struct list_head list;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+	struct ns_pid_list *tmp, *pos;
+
+	list_for_each_entry_safe(pos, tmp, head, list) {
+		list_del(&pos->list);
+		kfree(pos);
+	}
+}
+
+/*
+ * Only add pids with different ns
+ */
+static int
+ns_pid_list_really_add(struct pid *pid)
+{
+	struct ns_pid_list *tmp, *pos;
+
+	list_for_each_entry_safe(pos, tmp, &pidns_list, list)
+		if (ns_of_pid(pid) == ns_of_pid(pos->pid))
+			return 0;
+
+	return 1;
+}
+
+static int
+ns_pid_list_add(struct pid *pid)
+{
+	struct ns_pid_list *ent;
+
+	ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+	if (!ent)
+		return -ENOMEM;
+	ent->pid = pid;
+	if (ns_pid_list_really_add(pid))
+		list_add_tail(&ent->list, &pidns_list);
+
+	return 0;
+}
+
+static void print_list(void)
+{
+	struct ns_pid_list *tmp, *pos;
+	struct proc_dir_entry *parent, *parent_new;
+	struct pid_namespace *ns, *curr_ns;
+	struct pid *pid;
+	char name_buf[16], pid_buf[32];
+	int i, k;
+
+	curr_ns = task_active_pid_ns(current);
+
+	list_for_each_entry_safe(pos, tmp, &pidns_list, list) {
+		pid = pos->pid;
+		k = -1;
+		ns = pid->numbers[pid->level].ns;
+		/* Check whether pid has relationship with current ns */
+		for (; ns != NULL; ns = ns->parent)
+			if (ns == curr_ns)
+				k = curr_ns->level;
+		if (k == -1)
+			continue;
+		parent = proc_root;
+		for (i = k + 1; i <= pid->level; i++) {
+			ns = pid->numbers[i].ns;
+			snprintf(name_buf, 16, "pidns%u",
+				pid->numbers[i].ns->proc_inum);
+			snprintf(pid_buf, 32, "/proc/%u/ns/pid",
+				pid->numbers[0].nr);
+			/* don't duplicate ns dirs */
+			parent_new = proc_uniq_dir(parent, name_buf);
+			if (!parent_new) {
+				parent_new = proc_mkdir(name_buf, parent);
+				proc_symlink("pidns", parent_new, pid_buf);
+			}
+		parent = parent_new;
+		}
+	}
+}
+
+void proc_pidns_list(void)
+{
+	struct pid *pid;
+	struct task_struct *task = &init_task;
+
+	remove_proc_subtree(HIERARCHY_DIR, NULL);
+	proc_root = proc_mkdir(HIERARCHY_DIR, NULL);
+	free_pidns_list(&pidns_list);
+
+	do {
+		pid = task_pid(task);
+		if (pid) {
+			if (pid->level > 0)
+				ns_pid_list_add(pid);
+		}
+	} while ((task = next_task(task)) != &init_task);
+
+	print_list();
+	printk(KERN_INFO "refresh finished\n");
+}
+
+ssize_t proc_pidns_refresh_switch(struct file *file, const char __user *buf,
+		size_t size, loff_t *ppos)
+{
+	write_lock(&pidns_lock);
+	proc_pidns_list();
+	write_unlock(&pidns_lock);
+	return 1;
+}
+
+static const struct file_operations proc_pidns_refresh_fops = {
+	.write = proc_pidns_refresh_switch,
+};
+
+static int __init pidns_hierarchy_init(void)
+{
+
+	if (!proc_mkdir(BASE_DIR, NULL))
+		return -ENOMEM;
+	proc_root = proc_mkdir(HIERARCHY_DIR, NULL);
+	if (!proc_root)
+		return -ENOMEM;
+
+	proc_create(REFRESH_KEY, S_IWUGO,
+		NULL, &proc_pidns_refresh_fops);
+	printk(KERN_INFO "%s: loaded successfully\n", NAME);
+
+	return 0;
+}
+fs_initcall(pidns_hierarchy_init);
-- 
1.9.0

Re: [RFC PATCH 2/3] procfs: show hierarchy of pid namespace

[Vasiliy Kulikov]

Hi,

On Wed, Sep 03, 2014 at 18:29 +0800, Chen Hanxiao wrote:
> This patch will show the hierarchy of pid namespace
> under /proc/pidns like:
> /proc/pidns
> ├── hierarchy
> │   ├── pidns4026532399
> │   │   ├── pidns -> /proc/2863/ns/pid
> │   │   └── pidns4026532515
> │   │       └── pidns -> /proc/10611/ns/pid
> │   └── pidns4026532504
> │       └── pidns -> /proc/4450/ns/pid
> └── refresh

Re: this hierarchy:

1) I think it is a bit weird that there is a global hierarchy of NSs with
symlinks to actual NSs located in some random /proc/PID/ns/pid
directories.  It would be better to have a global tree with actual
directories and process directories would have symlinks to some subdirs
in this global tree.

2) The naming can be changed for even more trivial NSs traversal.
If the hierarchy is as following --

    hierarchy/
      pidns1234/
        pidns
        children/
          pidns3456/
            ...
          pidns5678/
            ...

-- then it is more simple to traverse the tree as child NSs are all
files in pidnsXXX/children/, not all files of the mask pidns[0-9]+.

> a) hierarchy dir:
>   use to show hierarchy infomation using dir and symlinks.
>   dirs are named as pidns($inum)
>   a symlink is created under pidns($inum), and linked to
>   that pid namespace.
> 
> b) refresh
>   trigger key.
>   We need to write sth to /proc/nspid/refresh,
>   then we could get hierarchy info
>   under /proc/pidns/hierarchy.
> 

-- 
Vasily

RE: [RFC PATCH 2/3] procfs: show hierarchy of pid namespace

[Chen, Hanxiao]

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

Hi,

> -----Original Message-----
> Hi,
> 
> On Wed, Sep 03, 2014 at 18:29 +0800, Chen Hanxiao wrote:
> > This patch will show the hierarchy of pid namespace
> > under /proc/pidns like:
> > /proc/pidns
> > ├── hierarchy
> > │   ├── pidns4026532399
> > │   │   ├── pidns -> /proc/2863/ns/pid
> > │   │   └── pidns4026532515
> > │   │       └── pidns -> /proc/10611/ns/pid
> > │   └── pidns4026532504
> > │       └── pidns -> /proc/4450/ns/pid
> > └── refresh
> 
> Re: this hierarchy:
> 
> 1) I think it is a bit weird that there is a global hierarchy of NSs with
> symlinks to actual NSs located in some random /proc/PID/ns/pid

It will be a symlink to the init process (PID 1) of that ns.
So it could stand for that namespace.

> directories.  It would be better to have a global tree with actual
> directories and process directories would have symlinks to some subdirs
> in this global tree.

Do you mean create symlinks from every /proc/PID/ns/pid to a global tree?
If that, 
a) we need to rebuild this global tree when pid ns changed.
	It would be a burden even if we don't need to know the hierarchy info. 
b) we need to prepare different tree views for different pid ns level.

> 
> 2) The naming can be changed for even more trivial NSs traversal.
> If the hierarchy is as following --
> 
>     hierarchy/
>       pidns1234/
>         pidns
>         children/
>           pidns3456/
>             ...
>           pidns5678/
>             ...
> 
> -- then it is more simple to traverse the tree as child NSs are all
> files in pidnsXXX/children/, not all files of the mask pidns[0-9]+.

Yeh, naming pidns($init_pid_in_ns) is good idea.
IIUC, my current proposal is the same as your opinion,
but free from children dir.

Tree view like your style:
init_pid_ns
       |
--- ns10--
|         |
ns20    ns21
          |
         ns30

And this patch suggested:
hierarchy/
└── nspid4026532393
    ├── nspid -> /proc/4652/ns/pid		--ns10
    ├── nspid4026532489
    │   └── nspid -> /proc/4701/ns/pid	--ns20
    └── nspid4026532496	
        ├── nspid -> /proc/4706/ns/pid	--ns21
        └── nspid4026532499
            └── nspid -> /proc/4714/ns/pid	--ns30


Thanks,
- Chen

> 
> > a) hierarchy dir:
> >   use to show hierarchy infomation using dir and symlinks.
> >   dirs are named as pidns($inum)
> >   a symlink is created under pidns($inum), and linked to
> >   that pid namespace.
> >
> > b) refresh
> >   trigger key.
> >   We need to write sth to /proc/nspid/refresh,
> >   then we could get hierarchy info
> >   under /proc/pidns/hierarchy.
> >
> 
> --
> Vasily
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [RFC PATCH 2/3] procfs: show hierarchy of pid namespace

[Serge E. Hallyn]

Quoting Chen Hanxiao (chenhanxiao@cn.fujitsu.com):
> This patch will show the hierarchy of pid namespace
> under /proc/pidns like:
> /proc/pidns
> ├── hierarchy
> │   ├── pidns4026532399
> │   │   ├── pidns -> /proc/2863/ns/pid
> │   │   └── pidns4026532515
> │   │       └── pidns -> /proc/10611/ns/pid
> │   └── pidns4026532504
> │       └── pidns -> /proc/4450/ns/pid
> └── refresh
> 
> a) hierarchy dir:
>   use to show hierarchy infomation using dir and symlinks.
>   dirs are named as pidns($inum)
>   a symlink is created under pidns($inum), and linked to
>   that pid namespace.
> 
> b) refresh
>   trigger key.
>   We need to write sth to /proc/nspid/refresh,
>   then we could get hierarchy info
>   under /proc/pidns/hierarchy.

Ouch.  There may not be a better way, but it sure would be nice if
we could simply have the list update in real-time.

If we have to 'echo 1 > /proc/pidns/refresh' to update the fs tree under
/proc/pidns/ to reflect new pidns activity, then why not just make this
a text file?  I suppose if it were a textfile you'd be encouraging ppl
to 'cat pidlist | while read line; do grep line /proc/pidns; done',
which would cause a refresh of that file for every grep?

My concern with this approach is that it is unlike any other pseudo-fs
that I know of, and people may simply expect the fs contents to be
uptodate rather than a snapshot.

> Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
> ---
>  fs/proc/Kconfig           |   6 ++
>  fs/proc/Makefile          |   1 +
>  fs/proc/pidns_hierarchy.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 168 insertions(+)
>  create mode 100644 fs/proc/pidns_hierarchy.c
> 
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 2183fcf..e2e2292 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
>  	  /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
>  	  /proc/kpagecount, and /proc/kpageflags. Disabling these
>            interfaces will reduce the size of the kernel by approximately 4kb.
> +
> +config PROC_PID_HIERARCHY
> +	bool "Enable /proc/pidns_hierarchy support" if EXPERT
> +	depends on PROC_FS
> +	help
> +	  Show pid namespace hierarchy infomation
> diff --git a/fs/proc/Makefile b/fs/proc/Makefile
> index 239493e..733599b 100644
> --- a/fs/proc/Makefile
> +++ b/fs/proc/Makefile
> @@ -29,3 +29,4 @@ proc-$(CONFIG_PROC_KCORE)	+= kcore.o
>  proc-$(CONFIG_PROC_VMCORE)	+= vmcore.o
>  proc-$(CONFIG_PRINTK)	+= kmsg.o
>  proc-$(CONFIG_PROC_PAGE_MONITOR)	+= page.o
> +proc-$(CONFIG_PROC_PID_HIERARCHY)	+= pidns_hierarchy.o
> diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
> new file mode 100644
> index 0000000..d35340f
> --- /dev/null
> +++ b/fs/proc/pidns_hierarchy.c
> @@ -0,0 +1,161 @@
> +/*
> + * proc_pidns_hierarchy.c -- handles pidns hierarchy
> + *
> + * Copyright 2014
> + */
> +
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/proc_fs.h>
> +#include <linux/module.h>
> +#include <linux/list.h>
> +#include <linux/slab.h>
> +#include <linux/pid_namespace.h>
> +
> +/*
> + * The /proc/pidns directory
> + */
> +
> +#define BASE_DIR	"pidns"			/* Subdir in /proc */
> +#define HIERARCHY_DIR	"pidns/hierarchy"	/* hierarchy dir */
> +#define REFRESH_KEY	"pidns/refresh"		/* refresh key */
> +#define NAME		"pidns_hierarchy"	/* Module name */
> +
> +static LIST_HEAD(pidns_list);
> +static DEFINE_RWLOCK(pidns_lock);
> +static struct proc_dir_entry *proc_root;
> +
> +struct ns_pid_list {
> +	struct pid *pid;
> +	struct list_head list;
> +};
> +
> +static void free_pidns_list(struct list_head *head)
> +{
> +	struct ns_pid_list *tmp, *pos;
> +
> +	list_for_each_entry_safe(pos, tmp, head, list) {
> +		list_del(&pos->list);
> +		kfree(pos);
> +	}
> +}
> +
> +/*
> + * Only add pids with different ns
> + */
> +static int
> +ns_pid_list_really_add(struct pid *pid)
> +{
> +	struct ns_pid_list *tmp, *pos;
> +
> +	list_for_each_entry_safe(pos, tmp, &pidns_list, list)
> +		if (ns_of_pid(pid) == ns_of_pid(pos->pid))
> +			return 0;
> +
> +	return 1;
> +}
> +
> +static int
> +ns_pid_list_add(struct pid *pid)
> +{
> +	struct ns_pid_list *ent;
> +
> +	ent = kmalloc(sizeof(*ent), GFP_KERNEL);
> +	if (!ent)
> +		return -ENOMEM;
> +	ent->pid = pid;
> +	if (ns_pid_list_really_add(pid))
> +		list_add_tail(&ent->list, &pidns_list);
> +
> +	return 0;
> +}
> +
> +static void print_list(void)
> +{
> +	struct ns_pid_list *tmp, *pos;
> +	struct proc_dir_entry *parent, *parent_new;
> +	struct pid_namespace *ns, *curr_ns;
> +	struct pid *pid;
> +	char name_buf[16], pid_buf[32];
> +	int i, k;
> +
> +	curr_ns = task_active_pid_ns(current);
> +
> +	list_for_each_entry_safe(pos, tmp, &pidns_list, list) {
> +		pid = pos->pid;
> +		k = -1;
> +		ns = pid->numbers[pid->level].ns;
> +		/* Check whether pid has relationship with current ns */
> +		for (; ns != NULL; ns = ns->parent)
> +			if (ns == curr_ns)
> +				k = curr_ns->level;
> +		if (k == -1)
> +			continue;
> +		parent = proc_root;
> +		for (i = k + 1; i <= pid->level; i++) {
> +			ns = pid->numbers[i].ns;
> +			snprintf(name_buf, 16, "pidns%u",
> +				pid->numbers[i].ns->proc_inum);
> +			snprintf(pid_buf, 32, "/proc/%u/ns/pid",
> +				pid->numbers[0].nr);
> +			/* don't duplicate ns dirs */
> +			parent_new = proc_uniq_dir(parent, name_buf);
> +			if (!parent_new) {
> +				parent_new = proc_mkdir(name_buf, parent);
> +				proc_symlink("pidns", parent_new, pid_buf);
> +			}
> +		parent = parent_new;
> +		}
> +	}
> +}
> +
> +void proc_pidns_list(void)
> +{
> +	struct pid *pid;
> +	struct task_struct *task = &init_task;
> +
> +	remove_proc_subtree(HIERARCHY_DIR, NULL);
> +	proc_root = proc_mkdir(HIERARCHY_DIR, NULL);
> +	free_pidns_list(&pidns_list);
> +
> +	do {
> +		pid = task_pid(task);
> +		if (pid) {
> +			if (pid->level > 0)
> +				ns_pid_list_add(pid);
> +		}
> +	} while ((task = next_task(task)) != &init_task);
> +
> +	print_list();
> +	printk(KERN_INFO "refresh finished\n");
> +}
> +
> +ssize_t proc_pidns_refresh_switch(struct file *file, const char __user *buf,
> +		size_t size, loff_t *ppos)
> +{
> +	write_lock(&pidns_lock);
> +	proc_pidns_list();
> +	write_unlock(&pidns_lock);
> +	return 1;
> +}
> +
> +static const struct file_operations proc_pidns_refresh_fops = {
> +	.write = proc_pidns_refresh_switch,
> +};
> +
> +static int __init pidns_hierarchy_init(void)
> +{
> +
> +	if (!proc_mkdir(BASE_DIR, NULL))
> +		return -ENOMEM;
> +	proc_root = proc_mkdir(HIERARCHY_DIR, NULL);
> +	if (!proc_root)
> +		return -ENOMEM;
> +
> +	proc_create(REFRESH_KEY, S_IWUGO,
> +		NULL, &proc_pidns_refresh_fops);
> +	printk(KERN_INFO "%s: loaded successfully\n", NAME);
> +
> +	return 0;
> +}
> +fs_initcall(pidns_hierarchy_init);
> -- 
> 1.9.0
> 
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

RE: [RFC PATCH 2/3] procfs: show hierarchy of pid namespace

[Chen, Hanxiao]

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



> -----Original Message-----
> From: Serge E. Hallyn [mailto:serge@hallyn.com]
> Sent: Thursday, September 11, 2014 12:23 AM
> To: Chen, Hanxiao/陈 晗霄
> Cc: containers@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> Richard Weinberger; Serge Hallyn; Oleg Nesterov; David Howells; Eric W. Biederman;
> Al Viro
> Subject: Re: [RFC PATCH 2/3] procfs: show hierarchy of pid namespace
> 
> Quoting Chen Hanxiao (chenhanxiao@cn.fujitsu.com):
> > This patch will show the hierarchy of pid namespace
> > under /proc/pidns like:
> > /proc/pidns
> > ├── hierarchy
> > │   ├── pidns4026532399
> > │   │   ├── pidns -> /proc/2863/ns/pid
> > │   │   └── pidns4026532515
> > │   │       └── pidns -> /proc/10611/ns/pid
> > │   └── pidns4026532504
> > │       └── pidns -> /proc/4450/ns/pid
> > └── refresh
> >
> > a) hierarchy dir:
> >   use to show hierarchy infomation using dir and symlinks.
> >   dirs are named as pidns($inum)
> >   a symlink is created under pidns($inum), and linked to
> >   that pid namespace.
> >
> > b) refresh
> >   trigger key.
> >   We need to write sth to /proc/nspid/refresh,
> >   then we could get hierarchy info
> >   under /proc/pidns/hierarchy.
> 
> Ouch.  There may not be a better way, but it sure would be nice if
> we could simply have the list update in real-time.
> 
> If we have to 'echo 1 > /proc/pidns/refresh' to update the fs tree under
> /proc/pidns/ to reflect new pidns activity, then why not just make this
> a text file?  I suppose if it were a textfile you'd be encouraging ppl
> to 'cat pidlist | while read line; do grep line /proc/pidns; done',
> which would cause a refresh of that file for every grep?

Let's expose it in a text file
and refresh it when user open it.
style like:

level1                    level2
/proc/2863/ns/pid /proc/10611/ns/pid 
/proc/4450/ns/pid

It provided fairly the same information as dir trees.
And easy to use too.

> 
> My concern with this approach is that it is unlike any other pseudo-fs
> that I know of, and people may simply expect the fs contents to be
> uptodate rather than a snapshot.
> 
You're right, snapshot is not a good idea.
v2 will use a file /proc/pidns_hierarchy to show.

Thanks,
- Chen

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

[PATCH 3/3] /proc/pid/status: show all sets of pid according to ns

[Chen Hanxiao]

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

This patch adds four fields: NStgid, NSpid, NSpgid and NSsid:
a) In init_pid_ns, nothing changed;

b) In one pidns, will tell the pid inside containers:
NStgid:	21776 	5 	1
NSpid:	21776 	5 	1
NSpgid:	21776 	5 	1
NSsid:	21729 	1 	0
** Process id is 21776 in level 0, 5 in level 1, 1 in level 2.

c) If pidns is nested, it depends on which pidns are you in.
NStgid:	5 	1
NSpid:	5 	1
NSpgid:	5 	1
NSsid:	1 	0
** Views from level 1

v2: add two new fields: NStgid and NSpid.
    keep fields of Tgid and Pid unchanged for back compatibility.
v3: add another two fields: NSpgid and NSsid.

Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
---
 fs/proc/array.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index cd3653e..c30875d 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
 		from_kgid_munged(user_ns, cred->egid),
 		from_kgid_munged(user_ns, cred->sgid),
 		from_kgid_munged(user_ns, cred->fsgid));
+	seq_puts(m, "NStgid:");
+	for (g = ns->level; g <= pid->level; g++)
+		seq_printf(m, "\t%d ",
+			task_tgid_nr_ns(p, pid->numbers[g].ns));
+	seq_puts(m, "\nNSpid:");
+	for (g = ns->level; g <= pid->level; g++)
+		seq_printf(m, "\t%d ",
+			task_pid_nr_ns(p, pid->numbers[g].ns));
+	seq_puts(m, "\nNSpgid:");
+	for (g = ns->level; g <= pid->level; g++)
+		seq_printf(m, "\t%d ",
+			task_pgrp_nr_ns(p, pid->numbers[g].ns));
+	seq_puts(m, "\nNSsid:");
+	for (g = ns->level; g <= pid->level; g++)
+		seq_printf(m, "\t%d ",
+			task_session_nr_ns(p, pid->numbers[g].ns));
+	seq_putc(m, '\n');
 
 	task_lock(p);
 	if (p->files)
-- 
1.9.0

Re: [RFC PATCH 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy

[Serge E. Hallyn]

Quoting Chen Hanxiao (chenhanxiao@cn.fujitsu.com):
> This series will expose pid inside containers
> via procfs.
> Also show the hierarchy of pid namespcae.
> Then we could know how pid looks inside a container
> and their ns relationships.
> 
> Chen Hanxiao (3):
>   procfs: check uniq proc_dir_entry subdir name
>   procfs: show hierarchy of pid namespace
>   /proc/pid/status: show all sets of pid according to ns
> 
>  fs/proc/Kconfig           |   6 ++
>  fs/proc/Makefile          |   1 +
>  fs/proc/array.c           |  17 +++++
>  fs/proc/generic.c         |  15 +++++
>  fs/proc/pidns_hierarchy.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/proc_fs.h   |   3 +
>  6 files changed, 203 insertions(+)
>  create mode 100644 fs/proc/pidns_hierarchy.c

Thanks, Chen.  I'm sorry I won't have a chance to review this week, but
hope to do next week.

RE: [RFC PATCH 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy

[Chen, Hanxiao]

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

Hi,

> -----Original Message-----
> Quoting Chen Hanxiao (chenhanxiao@cn.fujitsu.com):
> > This series will expose pid inside containers
> > via procfs.
> > Also show the hierarchy of pid namespcae.
> > Then we could know how pid looks inside a container
> > and their ns relationships.
> > 
> > Chen Hanxiao (3):
> >   procfs: check uniq proc_dir_entry subdir name
> >   procfs: show hierarchy of pid namespace
> >   /proc/pid/status: show all sets of pid according to ns
> > 
> >  fs/proc/Kconfig           |   6 ++
> >  fs/proc/Makefile          |   1 +
> >  fs/proc/array.c           |  17 +++++
> >  fs/proc/generic.c         |  15 +++++
> >  fs/proc/pidns_hierarchy.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/proc_fs.h   |   3 +
> >  6 files changed, 203 insertions(+)
> >  create mode 100644 fs/proc/pidns_hierarchy.c
> 
>Thanks, Chen.  I'm sorry I won't have a chance to review this week, but
>hope to do next week.
>

Thanks for your time and kindly help.

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

Re: [RFC PATCH 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy

[Serge E. Hallyn]

Hi,

so the below is just 30 mins worth of playing around, will hang if you give
it bad pids, and requires privilege, but shows how to get pid conversion
in some cases.  Basically it gives you what I had previously suggested
for the query_pid syscall before.

In general, usage is

translatepid reporter_pid dest_pid query_pid

where reporter_pid and dest_pid are pids in your pidns.  It will assume
query_pid is a valid pid in reporter_pid's pidns, and return the pid of
the same process in dest_pid's namespace.

In particular,

if a process in a container (say pid 1, pid 24444 in the host pidns)
reports something about another process (say pid 262) in the container,
and you have a shell (pid 1092) on the host, you can figure out the pid
for 262 in your host pidns using

translatepid $$ 24444 262

or to figure out what pid 25152 on the host is knows as in the
container,

translatepid 24444 $$ 25152

I wonder whether this is enough to give you all you need.  While it
won't be super-fast, you could use and ppid info to figure out who
is pid 1, etc.

#define _GNU_SOURCE             /* See feature_test_macros(7) */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/socket.h>
#include <fcntl.h>
#include <sys/un.h>
#include <sched.h>
#include <errno.h>

/*
 * general usage:
 *    translatepid reporter_ns_pid dest_ns_pid query_pid
 *
 * reporter_ns_pid and dest_ns_pid are pids in your namespace.
 * query_pid is in reporter_ns_pid's namespace.  The result is
 * in dest_ns_pid's namespace.
 *
 * If you see pid 10064 and want to know what it's vpid
 * is:
 *    translatepid $$ 10064 10064
 * If pid 10064 reported something about a pid 9 in its
 * own ns and you want to know what pid that is in your
 * ns:
 *    translatepid 10064 $$ 9
 *
 * First cpid1, in rpid's pidns, sends us query_pid.
 * Then we send that translated pid to cpid2, in dpid's pidns.
 * It prints out the answer
 */

static int proxyrecv(int sockfd, void *buf, size_t len)
{
	struct timeval tv;
	fd_set rfds;

	FD_ZERO(&rfds);
	FD_SET(sockfd, &rfds);
	tv.tv_sec = 2;
	tv.tv_usec = 0;

	if (select(sockfd+1, &rfds, NULL, NULL, &tv) < 0)
		return -1;
	return recv(sockfd, buf, len, MSG_DONTWAIT);
}

void send_creds(int sock, struct ucred *cred)
{
	struct msghdr msg = { 0 };
	struct iovec iov;
	struct cmsghdr *cmsg;
	char cmsgbuf[CMSG_SPACE(sizeof(*cred))];
	char buf[1];
	buf[0] = 'p';

	if (proxyrecv(sock, buf, 1) != 1) {
		printf("%s: Error getting reply from server over socketpair",
			  __func__);
		exit(1);
	}

	msg.msg_control = cmsgbuf;
	msg.msg_controllen = sizeof(cmsgbuf);

	cmsg = CMSG_FIRSTHDR(&msg);
	cmsg->cmsg_len = CMSG_LEN(sizeof(struct ucred));
	cmsg->cmsg_level = SOL_SOCKET;
	cmsg->cmsg_type = SCM_CREDENTIALS;
	memcpy(CMSG_DATA(cmsg), cred, sizeof(*cred));

	msg.msg_name = NULL;
	msg.msg_namelen = 0;

	iov.iov_base = buf;
	iov.iov_len = sizeof(buf);
	msg.msg_iov = &iov;
	msg.msg_iovlen = 1;

	if (sendmsg(sock, &msg, 0) < 0) {
		printf("%s: failed at sendmsg: %s", __func__,
			  strerror(errno));
		exit(1);
	}
}

void recv_creds(int sock, struct ucred *cred)
{
	struct msghdr msg = { 0 };
	struct iovec iov;
	struct cmsghdr *cmsg;
	char cmsgbuf[CMSG_SPACE(sizeof(*cred))];
	char buf[1];
	int ret;
	int optval = 1;

	cred->pid = -1;
	cred->uid = -1;
	cred->gid = -1;

	if (setsockopt(sock, SOL_SOCKET, SO_PASSCRED, &optval, sizeof(optval)) == -1) {
		printf("Failed to set passcred: %s", strerror(errno));
		return;
	}
	buf[0] = '1';
	if (write(sock, buf, 1) != 1) {
		printf("Failed to start write on scm fd: %s", strerror(errno));
		return;
	}

	msg.msg_name = NULL;
	msg.msg_namelen = 0;
	msg.msg_control = cmsgbuf;
	msg.msg_controllen = sizeof(cmsgbuf);

	iov.iov_base = buf;
	iov.iov_len = sizeof(buf);
	msg.msg_iov = &iov;
	msg.msg_iovlen = 1;

	// retry logic is not ideal, especially as we are not
	// threaded.  Sleep at most 1 second waiting for the client
	// to send us the scm_cred
	ret = recvmsg(sock, &msg, 0);
	if (ret < 0) {
		printf("Failed to receive scm_cred: %s",
			  strerror(errno));
		return;
	}

	cmsg = CMSG_FIRSTHDR(&msg);

	if (cmsg && cmsg->cmsg_len == CMSG_LEN(sizeof(struct ucred)) &&
			cmsg->cmsg_level == SOL_SOCKET &&
			cmsg->cmsg_type == SCM_CREDENTIALS) {
		memcpy(cred, CMSG_DATA(cmsg), sizeof(*cred));
	}
}

int main(int argc, char *argv[])
{
	pid_t rpid, dpid, qpid;
	pid_t cpid1, cpid2;
	int optval = 1;
	struct ucred u;
	char path[100];
	int fd;

	int sv[2];

	if (argc != 4) {
		printf("Usage: %s report_pid dest_pid query_pid\n", argv[0]);
		exit(1);
	}

	if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sv) < 0) {
		perror("socketpair");
		exit(1);
	}
	rpid = atoi(argv[1]);
	dpid = atoi(argv[2]);
	qpid = atoi(argv[3]);

	if ((cpid1 = fork()) < 0) {
		perror("fork");
		exit(1);
	}
	if (cpid1 == 0) {
		int xpid;
		sprintf(path, "/proc/%d/ns/pid", rpid);
		fd = open(path, O_RDWR);
		if (fd < 0) {
			perror("open of nspid");
			exit(1);
		}
		if (setns(fd, 0) < 0) {
			perror("setns");
			exit(1);
		}
		if ((xpid = fork()) < 0)
			exit(1);
		if (xpid == 0) {
			u.uid = 0;  u.gid = 0;  u.pid = qpid;
			send_creds(sv[0], &u);
		}
		exit(0);
	}
	recv_creds(sv[1], &u);

	close(sv[0]);
	close(sv[1]);

	if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sv) < 0) {
		perror("socketpair");
		exit(1);
	}
	if ((cpid2 = fork()) < 0) {
		perror("fork");
		exit(1);
	}

	if (cpid2 == 0) {
		pid_t xpid;
		sprintf(path, "/proc/%d/ns/pid", dpid);
		fd = open(path, O_RDWR);
		if (fd < 0) {
			perror("open of nspid");
			exit(1);
		}
		if (setns(fd, 0) < 0) {
			perror("setns");
			exit(1);
		}
		if ((xpid = fork()) < 0)
			exit(1);
		if (xpid == 0) {
			recv_creds(sv[1], &u);
			printf("pid is: %d\n", (int) u.pid);
		}
		exit(0);
	}

	send_creds(sv[0], &u);

	waitpid(cpid2, NULL, 0);
	exit(0);
}

RE: [RFC PATCH 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy

[Chen, Hanxiao]

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

Hi,

> -----Original Message-----
> From: Serge E. Hallyn [mailto:serge@hallyn.com]
> 
> Hi,
> 
> so the below is just 30 mins worth of playing around, will hang if you give
> it bad pids, and requires privilege, but shows how to get pid conversion
> in some cases.  Basically it gives you what I had previously suggested
> for the query_pid syscall before.
> 
Thanks for teaching me of how ucred could be used for this case.

> In general, usage is
> 
> translatepid reporter_pid dest_pid query_pid
> 
> where reporter_pid and dest_pid are pids in your pidns.  It will assume
> query_pid is a valid pid in reporter_pid's pidns, and return the pid of
> the same process in dest_pid's namespace.
> 
> In particular,
> 
> if a process in a container (say pid 1, pid 24444 in the host pidns)
> reports something about another process (say pid 262) in the container,
> and you have a shell (pid 1092) on the host, you can figure out the pid
> for 262 in your host pidns using
> 
> translatepid $$ 24444 262
> 
> or to figure out what pid 25152 on the host is knows as in the
> container,
> 
> translatepid 24444 $$ 25152
> 
It's very easy to use:)

> I wonder whether this is enough to give you all you need.  While it
> won't be super-fast, you could use and ppid info to figure out who
> is pid 1, etc.

Yes, functionally it's very good.
But for the cases of utilizes like sosreport, ps,
it's a bit of slow.

So the procfs still has its advantages.
And also, I think the pidns hierarchy is needed.
I'll send the v2 ns hierarchy patch soon.

Thanks,
- Chen

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