OpenVZ Forum - RDF feed
type: channel
items: [PATCH 0/16] Pid namespaces
items: [PATCH 1/16] Round up the API
items: [PATCH 2/16] Miscelaneous preparations for namespaces
items: [PATCH 3/16] Introduce MS_KERNMOUNT flag
items: [PATCH 4/16] Change data structures for pid namespaces
items: [PATCH 5/16] Make proc be mountable from different pid namespaces
items: [PATCH 6/16] Helpers to obtain pid numbers
items: [PATCH 7/16] Helpers to find the task by its numerical ids
items: [PATCH 8/16] Masquerade the siginfo when sending a pid to a foreign namespace
items: [PATCH 9/16] Make proc_flust_task to flush entries from multiple proc trees
items: [PATCH 10/16] Changes in copy_process() to work with pid namespaces
items: [PATCH 11/16] Add support for multiple kmem caches for pids
items: [PATCH 12/16] Reference counting of pid naspaces by pids
items: [PATCH 13/16] Switch to operating with pid_numbers instead of pids
items: [PATCH 14/16] Make pid namespaces clonnable
items: [PATCH 15/16] Changes to show virtual ids to user
items: [PATCH 16/16] Remove already unneeded memners from struct pid
items: Re: [PATCH 0/16] Pid namespaces
items: Re: [PATCH 1/16] Round up the API
items: Re: [PATCH 2/16] Miscelaneous preparations for namespaces
items: Re: [PATCH 4/16] Change data structures for pid namespaces
items: Re: [PATCH 7/16] Helpers to find the task by its numerical ids
items: Re: [PATCH 8/16] Masquerade the siginfo when sending a pid to a foreign namespace
items: Re: [PATCH 6/16] Helpers to obtain pid numbers
items: Re: [PATCH 10/16] Changes in copy_process() to work with pid namespaces
items: Re: [PATCH 13/16] Switch to operating with pid_numbers instead of pids

[PATCH 0/16] Pid namespaces
type: item
description: This is "submition for inclusion" of hierarchical, not kconfig configurable, zero overheaded ;) pid namespaces. The overall idea is the following: The namespace are organized as a tree - once a task is cloned with CLONE_NEWPIDS (yes, I've also switched to it :) the new namespace becomes the parent's child and tasks living in the parent namespace see the tasks from the new one. The numerical ids are used on the kernel-user boundary, i.e. when we export pid to user we show the id, that should be used to address the task in question from the namespace we're exporting this id to. The main difference from Suka's patches are the following: 0. Suka's patches change the kernel/pid.c code too heavy. This set keeps the kernel code look like it was without the patches. However, this is a minor issue. The major is: 1. Suka's approach is to remove the notion of the task's numerical pid from the kernel at all. The numbers are used on the kernel-user boundary or within the kernel but with the namespace this nr belongs to. This results in massive changes of struct's members fro int pid to struct pid *pid, task->pid becomes the virtual id and so on and so forth. My approach is to keep the good old logic in the kernel. The task->pid is a global and unique pid, find_pid() finds the pid by its global id and so on. The virtual ids appear on the user-kernel boundary only. Thus drivers and other kernel code may still be unaware of pids unless they do not communicate with the userspace and get/put numerical pids. And some more minor differences: 2. Suka's patches have the limit of pid namespace nesting. My patches do not. 3. Suka assumes that pid namespace can live without proc mount and tries to make the code work with pid_ns->proc_mnt change from NULL to not-NULL from times to times. My code calls the kern_mount() at the namespace creation and thus the pid_namespace always works with proc. There are some small issues that I can describe if someone is interested. The tests like nptl perf,…
creator: Pavel Emelianov
date: 2007-07-06T08:01:59-00:00

[PATCH 1/16] Round up the API
type: item
description: The set of functions process_session, task_session, process_group and task_pgrp is confusing, as the names can be mixed with each other when looking at the code for a long time. The proposals are to * equip the functions that return the integer with _nr suffix to represent that fact, * and to make all functions work with task (not process) by making the common prefix of the same name. For monotony the routines signal_session() and set_signal_session() are replaced with task_session_nr() and set_task_session(), especially since they are only used with the explicit task->signal dereference. Signed-off-by: Pavel Emelianov <xemul@openvz.org> Acked-by: Serge E. Hallyn <serue@us.ibm.com> --- arch/mips/kernel/irixelf.c | 4 ++-- arch/mips/kernel/irixsig.c | 2 +- arch/mips/kernel/sysirix.c | 4 ++-- arch/sparc64/solaris/misc.c | 4 ++-- drivers/char/tty_io.c | 4 ++-- fs/autofs/inode.c | 2 +- fs/autofs/root.c | 4 ++-- fs/autofs4/autofs_i.h | 2 +- fs/autofs4/inode.c | 4 ++-- fs/autofs4/root.c | 4 ++-- fs/binfmt_elf.c | 8 ++++---- fs/binfmt_elf_fdpic.c | 8 ++++---- fs/coda/upcall.c | 2 +- fs/proc/array.c | 4 ++-- include/linux/sched.h | 15 +++++---------- kernel/exit.c | 10 +++++----- kernel/fork.c | 4 ++-- kernel/signal.c | 2 +- kernel/sys.c | 14 +++++++------- 19 files changed, 48 insertions(+), 53 deletions(-) --- ./arch/mips/kernel/irixelf.c.apiren 2007-06-14 12:14:29.000000000 +0400 +++ ./arch/mips/kernel/irixelf.c 2007-06-14 15:52:54.000000000 +0400 @@ -1170,8 +1170,8 @@ static int irix_core_dump(long signr, st prstatus.pr_sighold = current->blocked.sig[0]; psinfo.pr_pid = prstatus.pr_pid = current->pid; psinfo.pr_ppid = prstatus.pr_ppid = current->parent->pid; - psinfo.pr_pgrp = prstatus.pr_pgrp = process_group(current); - psinfo.pr_sid = prstatus.pr_sid = process_session(current); + psinfo.pr_pgrp = prstatus.pr_pgrp = task_pgrp_nr(current); + psinfo.pr_sid = prstatus.pr_sid = task_session_nr(current); if (current->pid == current->tgid) { /* * This is the record for the gr…
creator: Pavel Emelianov
date: 2007-07-06T08:03:17-00:00

[PATCH 2/16] Miscelaneous preparations for namespaces
type: item
description: The most importaint change is moving exit_task_namespaces() inside exit_notify() to makes it possible to notify the exiting task's parent. However this should be done before release_task() to address the issue pointed by Sukadev with NFS kernel thread. Other changes are small and do not deserve separate description. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- include/linux/pid_namespace.h | 7 ++++--- kernel/exit.c | 3 ++- kernel/pid.c | 2 ++ 3 files changed, 8 insertions(+), 4 deletions(-) --- ./include/linux/pid_namespace.h.ve1 2007-07-06 10:58:57.000000000 +0400 +++ ./include/linux/pid_namespace.h 2007-07-06 11:03:18.000000000 +0400 @@ -4,7 +4,6 @@ #include <linux/sched.h> #include <linux/mm.h> #include <linux/threads.h> -#include <linux/pid.h> #include <linux/nsproxy.h> #include <linux/kref.h> @@ -24,9 +23,10 @@ struct pid_namespace { extern struct pid_namespace init_pid_ns; -static inline void get_pid_ns(struct pid_namespace *ns) +static inline struct pid_namespace *get_pid_ns(struct pid_namespace *ns) { kref_get(&ns->kref); + return ns; } extern struct pid_namespace *copy_pid_ns(unsigned long flags, struct pid_namespace *ns); @@ -39,7 +39,8 @@ static inline void put_pid_ns(struct pid static inline struct task_struct *child_reaper(struct task_struct *tsk) { - return init_pid_ns.child_reaper; + BUG_ON(tsk != current); + return tsk->nsproxy->pid_ns->child_reaper; } #endif /* _LINUX_PID_NS_H */ --- ./kernel/exit.c.ve1 2007-07-06 11:02:55.000000000 +0400 +++ ./kernel/exit.c 2007-07-06 11:02:55.000000000 +0400 @@ -862,6 +862,8 @@ static void exit_notify(struct task_stru release_task(t); } + exit_task_namespaces(tsk); + /* If the process is dead, release it - nobody will wait for it */ if (state == EXIT_DEAD) release_task(tsk); @@ -1002,7 +1004,6 @@ fastcall NORET_TYPE void do_exit(long co tsk->exit_code = code; proc_exit_connector(tsk); - exit_task_namespaces(tsk); exit_notify(tsk); #ifdef CONFIG_NUMA mpol_free(tsk->mempolicy); --- ./kernel/pid.c.ve1 2007-0…
creator: Pavel Emelianov
date: 2007-07-06T08:03:54-00:00

[PATCH 3/16] Introduce MS_KERNMOUNT flag
type: item
description: This flag tells the .get_sb callback that this is a kern_mount() call so that it can trust *data pointer to be valid in-kernel one. Running a few steps forward - this will be needed for proc to create the superblock and store a valid pid namespace on it during the namespace creation. The reason, why the namespace cannot live without proc mount is described in the appropriate patch. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- fs/namespace.c | 3 ++- fs/super.c | 6 +++--- include/linux/fs.h | 4 +++- 3 files changed, 8 insertions(+), 5 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/fs/namespace.c linux-2.6.22-rc4-mm2-2/fs/namespace.c --- linux-2.6.22-rc4-mm2.orig/fs/namespace.c 2007-06-14 12:00:06.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/fs/namespace.c 2007-07-04 19:00:39.000000000 +0400 @@ -1558,7 +1558,8 @@ long do_mount(char *dev_name, char *dir_ mnt_flags |= MNT_NOMNT; flags &= ~(MS_NOSUID | MS_NOEXEC | MS_NODEV | MS_ACTIVE | - MS_NOATIME | MS_NODIRATIME | MS_RELATIME | MS_NOMNT); + MS_NOATIME | MS_NODIRATIME | MS_RELATIME | + MS_NOMNT | MS_KERNMOUNT); /* ... and get the mountpoint */ retval = path_lookup(dir_name, LOOKUP_FOLLOW, &nd); diff -upr linux-2.6.22-rc4-mm2.orig/fs/super.c linux-2.6.22-rc4-mm2-2/fs/super.c --- linux-2.6.22-rc4-mm2.orig/fs/super.c 2007-06-07 15:37:30.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/fs/super.c 2007-07-04 19:00:39.000000000 +0400 @@ -942,9 +942,9 @@ do_kern_mount(const char *fstype, int fl return mnt; } -struct vfsmount *kern_mount(struct file_system_type *type) +struct vfsmount *kern_mount_data(struct file_system_type *type, void *data) { - return vfs_kern_mount(type, 0, type->name, NULL); + return vfs_kern_mount(type, MS_KERNMOUNT, type->name, data); } -EXPORT_SYMBOL(kern_mount); +EXPORT_SYMBOL_GPL(kern_mount_data); diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/fs.h linux-2.6.22-rc4-mm2-2/include/linux/fs.h --- linux-2.6.22-rc4-mm2.orig/include/linux/fs.h 2007-06-14 12:00:06.000000000 +0400 +++ linux-2.6.22-rc4-m…
creator: Pavel Emelianov
date: 2007-07-06T08:04:28-00:00

[PATCH 4/16] Change data structures for pid namespaces
type: item
description: struct pid_namespace will have the kmem_cache to allocate the pids from, the parent, as they are hierarchical, and the level of nesting value. struct pid will have a variable length array of pid_number-s one for each namespace this pid lives in. The level value shows the level of the namespace this pid lives in and thus - the number of elements in the numbers array. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- include/linux/init_task.h | 6 ++++++ include/linux/pid.h | 9 +++++++++ include/linux/pid_namespace.h | 3 +++ kernel/pid.c | 3 ++- 4 files changed, 20 insertions(+), 1 deletion(-) diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 @@ -40,6 +40,13 @@ enum pid_type * processes. */ +struct pid_number { + /* Try to keep pid_chain in the same cacheline as nr for find_pid */ + int nr; + struct pid_namespace *ns; + struct hlist_node pid_chain; +}; + struct pid { atomic_t count; @@ -40,6 +40,8 @@ enum pid_type /* lists of tasks that use this pid */ struct hlist_head tasks[PIDTYPE_MAX]; struct rcu_head rcu; + int level; + struct pid_number numbers[1]; }; extern struct pid init_struct_pid; diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h --- linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h 2007-07-04 19:00:39.000000000 +0400 @@ -16,7 +15,10 @@ struct pidmap { struct kref kref; struct pidmap pidmap[PIDMAP_ENTRIES]; int last_pid; + int level; struct task_struct *child_reaper; + struct kmem_cache *pid_cachep; + struct pid_namespace *parent; }; extern struct pid_namespace init_pid_ns; diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/init_task.h linux-2.6.22-rc4-mm2-2/include/linux/init…
creator: Pavel Emelianov
date: 2007-07-06T08:05:00-00:00

[PATCH 5/16] Make proc be mountable from different pid namespaces
type: item
description: Each pid namespace should have the proc_mnt pointer even when there's no user mounts to make proc_flush_task() work. To do this we call the kern_mount() to obtain the proc mount point. Since the current pid_namespace during this call is not the newly created one we use the introduced MS_KERNMOUNT flag to pass the namespace pointer to the proc_get_sb() call. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- fs/proc/inode.c | 20 +++++-- fs/proc/internal.h | 2 fs/proc/root.c | 116 ++++++++++++++++++++++++++++++++++++++++-- include/linux/pid_namespace.h | 3 + include/linux/proc_fs.h | 15 +++++ 5 files changed, 147 insertions(+), 9 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/fs/proc/inode.c linux-2.6.22-rc4-mm2-2/fs/proc/inode.c --- linux-2.6.22-rc4-mm2.orig/fs/proc/inode.c 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/fs/proc/inode.c 2007-07-04 19:00:38.000000000 +0400 @@ -16,6 +16,7 @@ #include <linux/init.h> #include <linux/module.h> #include <linux/smp_lock.h> +#include <linux/pid_namespace.h> #include <asm/system.h> #include <asm/uaccess.h> @@ -429,9 +430,17 @@ out_mod: return NULL; } -int proc_fill_super(struct super_block *s, void *data, int silent) +int proc_fill_super(struct super_block *s, struct pid_namespace *ns) { struct inode * root_inode; + struct proc_dir_entry * root_dentry; + + root_dentry = &proc_root; + if (ns != &init_pid_ns) { + root_dentry = create_proc_root(); + if (root_dentry == NULL) + goto out_no_de; + } s->s_flags |= MS_NODIRATIME | MS_NOSUID | MS_NOEXEC; s->s_blocksize = 1024; @@ -440,8 +449,8 @@ int proc_fill_super(struct super_block * s->s_op = &proc_sops; s->s_time_gran = 1; - de_get(&proc_root); - root_inode = proc_get_inode(s, PROC_ROOT_INO, &proc_root); + de_get(root_dentry); + root_inode = proc_get_inode(s, PROC_ROOT_INO, root_dentry); if (!root_inode) goto out_no_root; root_inode->i_uid = 0; @@ -452,9 +461,10 @@ int proc_fill_super(struct super_block * return 0; out_no_root: - printk("proc_read_super: get ro…
creator: Pavel Emelianov
date: 2007-07-06T08:05:42-00:00

[PATCH 6/16] Helpers to obtain pid numbers
type: item
description: When showing pid to user or getting the pid numerical id for in-kernel use the value of this id may differ depending on the namespace. This set of helpers is used to get the global pid nr, the virtual (i.e. seen by task in its namespace) nr and the nr as it is seen from the specified namespace. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- include/linux/pid.h | 27 ++++++++++++ include/linux/sched.h | 108 +++++++++++++++++++++++++++++++++++++++++++++----- kernel/pid.c | 8 +++ 3 files changed, 132 insertions(+), 11 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 @@ -83,6 +89,9 @@ extern void FASTCALL(detach_pid(struct t extern void FASTCALL(transfer_pid(struct task_struct *old, struct task_struct *new, enum pid_type)); +struct pid_namespace; +extern struct pid_namespace init_pid_ns; + /* * look up a PID in the hash table. Must be called with the tasklist_lock * or rcu_read_lock() held. @@ -93,14 +99,36 @@ extern void FASTCALL(detach_pid(struct t extern struct pid *alloc_pid(void); extern void FASTCALL(free_pid(struct pid *pid)); +/* + * the helpers to get the pid's id seen from different namespaces + * + * pid_nr() : global id, i.e. the id seen from the init namespace; + * pid_vnr() : virtual id, i.e. the id seen from the namespace this pid + * belongs to. this only makes sence when called in the + * context of the task that belongs to the same namespace; + * pid_nr_ns() : id seen from the ns specified. + * + * see also task_xid_nr() etc in include/linux/sched.h + */ + static inline pid_t pid_nr(struct pid *pid) { pid_t nr = 0; if (pid) - nr = pid->nr; + nr = pid->numbers[0].nr; return nr; } +pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns); + +static inline pid_t pid_vnr(struct pid *pid) +{ + pid_t nr = 0; + if (pid) + n…
creator: Pavel Emelianov
date: 2007-07-06T08:06:22-00:00

[PATCH 7/16] Helpers to find the task by its numerical ids
type: item
description: When searching the task by numerical id on may need to find it using global pid (as it is done now in kernel) or by its virtual id, e.g. when sending a signal to a task from one namespace the sender will specify the task's virtual id. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- fs/proc/base.c | 2 +- include/linux/pid.h | 13 +++++++++++-- include/linux/sched.h | 31 +++++++++++++++++++++++++++++-- kernel/pid.c | 32 +++++++++++++++++--------------- 4 files changed, 58 insertions(+), 20 deletions(-) --- ./fs/proc/base.c.ve6 2007-07-06 10:58:56.000000000 +0400 +++ ./fs/proc/base.c 2007-07-06 11:03:41.000000000 +0400 @@ -2230,7 +2230,7 @@ static struct task_struct *next_tgid(uns rcu_read_lock(); retry: task = NULL; - pid = find_ge_pid(tgid); + pid = find_ge_pid(tgid, &init_pid_ns); if (pid) { tgid = pid->nr + 1; task = pid_task(pid, PIDTYPE_PID); --- ./include/linux/pid.h.ve6 2007-07-06 11:03:27.000000000 +0400 +++ ./include/linux/pid.h 2007-07-06 11:03:27.000000000 +0400 @@ -98,14 +98,23 @@ extern struct pid_namespace init_pid_ns; /* * look up a PID in the hash table. Must be called with the tasklist_lock * or rcu_read_lock() held. + * + * find_pid_ns() finds the pid in the namespace specified + * find_pid() find the pid by its global id, i.e. in the init namespace + * find_vpid() finr the pid by its virtual id, i.e. in the current namespace + * + * see also find_task_by_pid() set in include/linux/sched.h */ -extern struct pid *FASTCALL(find_pid(int nr)); +extern struct pid *FASTCALL(find_pid_ns(int nr, struct pid_namespace *ns)); + +#define find_vpid(pid) find_pid_ns(pid, current->nsproxy->pid_ns) +#define find_pid(pid) find_pid_ns(pid, &init_pid_ns) /* * Lookup a PID in the hash table, and return with it's count elevated. */ extern struct pid *find_get_pid(int nr); -extern struct pid *find_ge_pid(int nr); +extern struct pid *find_ge_pid(int nr, struct pid_namespace *); extern struct pid *alloc_pid(void); extern void FASTCALL(free_pid(struct pid *pid)); --- ./…
creator: Pavel Emelianov
date: 2007-07-06T08:07:02-00:00

[PATCH 8/16] Masquerade the siginfo when sending a pid to a foreign namespace
type: item
description: When user send signal from (say) init namespace to any task in a sub namespace the siginfo struct must not carry the sender's pid value, as this value may refer to some task in the destination namespace and thus may confuse the application. The consensus was to pretend in this case as if it is the kernel who sends the signal. The pid_ns_accessible() call is introduced to check this pid-to-ns accessibility. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- include/linux/pid.h | 10 ++++++++++ kernel/signal.c | 34 ++++++++++++++++++++++++++++------ 2 files changed, 38 insertions(+), 6 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 @@ -83,6 +89,16 @@ extern void FASTCALL(detach_pid(struct t return nr; } +/* + * checks whether the pid actually lives in the namespace ns, i.e. it was + * created in this namespace or it was moved there. + */ + +static inline int pid_ns_accessible(struct pid_namespace *ns, struct pid *pid) +{ + return pid->numbers[pid->level].ns == ns; +} + #define do_each_pid_task(pid, type, task) \ do { \ struct hlist_node *pos___; \ diff -upr linux-2.6.22-rc4-mm2.orig/kernel/signal.c linux-2.6.22-rc4-mm2-2/kernel/signal.c --- linux-2.6.22-rc4-mm2.orig/kernel/signal.c 2007-07-04 19:00:38.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/kernel/signal.c 2007-07-04 19:00:38.000000000 +0400 @@ -1124,13 +1124,31 @@ EXPORT_SYMBOL_GPL(kill_pid_info_as_uid); * is probably wrong. Should make it like BSD or SYSV. */ -static int kill_something_info(int sig, struct siginfo *info, int pid) +static inline void masquerade_siginfo(struct pid_namespace *src_ns, + struct pid *tgt_pid, struct siginfo *info) +{ + if (tgt_pid != NULL && !pid_ns_accessible(src_ns, tgt_pid)) { + /* + * current namespace is not seen from the taks we + * want to send th…
creator: Pavel Emelianov
date: 2007-07-06T08:07:37-00:00

[PATCH 9/16] Make proc_flust_task to flush entries from multiple proc trees
type: item
description: Since a task will appear in more than one proc tree we need to shrink many trees. For this case we pass the struct pid to proc_flush_task() and shrink the mounts of all the namespaces this pid belongs to. The NULL passed to it means that only global mount is to be flushed. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- fs/proc/base.c | 25 ++++++++++++++++++++++--- include/linux/proc_fs.h | 6 ++++-- kernel/exit.c | 18 +++++++++++++++++- 3 files changed, 43 insertions(+), 6 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/fs/proc/base.c linux-2.6.22-rc4-mm2-2/fs/proc/base.c --- linux-2.6.22-rc4-mm2.orig/fs/proc/base.c 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/fs/proc/base.c 2007-07-04 19:00:38.000000000 +0400 @@ -75,6 +75,7 @@ #include <linux/nsproxy.h> #include <linux/oom.h> #include <linux/elf.h> +#include <linux/pid_namespace.h> #include "internal.h" /* NOTE: @@ -2183,7 +2184,7 @@ static const struct inode_operations pro * that no dcache entries will exist at process exit time it * just makes it very unlikely that any will persist. */ -void proc_flush_task(struct task_struct *task) +static void proc_flush_task_mnt(struct task_struct *task, struct vfsmount *mnt) { struct dentry *dentry, *leader, *dir; char buf[PROC_NUMBUF]; @@ -2191,7 +2192,7 @@ void proc_flush_task(struct task_struct name.name = buf; name.len = snprintf(buf, sizeof(buf), "%d", task->pid); - dentry = d_hash_and_lookup(proc_mnt->mnt_root, &name); + dentry = d_hash_and_lookup(mnt->mnt_root, &name); if (dentry) { shrink_dcache_parent(dentry); d_drop(dentry); @@ -2203,7 +2204,7 @@ void proc_flush_task(struct task_struct name.name = buf; name.len = snprintf(buf, sizeof(buf), "%d", task->tgid); - leader = d_hash_and_lookup(proc_mnt->mnt_root, &name); + leader = d_hash_and_lookup(mnt->mnt_root, &name); if (!leader) goto out; @@ -2229,6 +2230,24 @@ out: return; } +/* + * when flushing dentries from proc one need to flush them from global + * proc (proc_mnt) and from all the names…
creator: Pavel Emelianov
date: 2007-07-06T08:08:09-00:00

[PATCH 10/16] Changes in copy_process() to work with pid namespaces
type: item
description: We must pass the namespace pointer to the alloc_pid() to show what namespace to allocate the pid from and we should call this *after* the namespace is copied. Essentially, the task->pid etc initialization is done after the alloc_pid(). To do so I move the alloc_pid() inside copy_process() and introduce an argument to the alloc_pid() function. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- include/linux/pid.h | 2 +- kernel/fork.c | 29 +++++++++++++++++------------ kernel/pid.c | 2 +- 3 files changed, 19 insertions(+), 14 deletions(-) --- ./include/linux/pid.h.ve9 2007-07-06 11:03:55.000000000 +0400 +++ ./include/linux/pid.h 2007-07-06 11:03:55.000000000 +0400 @@ -116,7 +116,7 @@ extern struct pid *FASTCALL(find_pid_ns( extern struct pid *find_get_pid(int nr); extern struct pid *find_ge_pid(int nr, struct pid_namespace *); -extern struct pid *alloc_pid(void); +extern struct pid *alloc_pid(struct pid_namespace *ns); extern void FASTCALL(free_pid(struct pid *pid)); /* --- ./kernel/fork.c.ve9 2007-07-06 11:03:55.000000000 +0400 +++ ./kernel/fork.c 2007-07-06 11:04:07.000000000 +0400 @@ -50,6 +50,7 @@ #include <linux/taskstats_kern.h> #include <linux/random.h> #include <linux/tty.h> +#include <linux/pid.h> #include <asm/pgtable.h> #include <asm/pgalloc.h> @@ -1032,7 +1033,6 @@ static struct task_struct *copy_process( p->did_exec = 0; delayacct_tsk_init(p); /* Must remain after dup_task_struct() */ copy_flags(clone_flags, p); - p->pid = pid_nr(pid); INIT_LIST_HEAD(&p->children); INIT_LIST_HEAD(&p->sibling); p->vfork_done = NULL; @@ -1107,10 +1107,6 @@ static struct task_struct *copy_process( p->blocked_on = NULL; /* not blocked yet */ #endif - p->tgid = p->pid; - if (clone_flags & CLONE_THREAD) - p->tgid = current->tgid; - if ((retval = security_task_alloc(p))) goto bad_fork_cleanup_policy; if ((retval = audit_alloc(p))) @@ -1132,9 +1128,14 @@ static struct task_struct *copy_process( goto bad_fork_cleanup_mm; if ((retval = copy_namespaces(clone_flags, p))) goto bad_…
creator: Pavel Emelianov
date: 2007-07-06T08:08:40-00:00

[PATCH 11/16] Add support for multiple kmem caches for pids
type: item
description: Unike Suka's patches I don not limit the level of pid nesting creating the caches on demand, depending on the namespace's level. Each kmem cache is names "pid_<NR>", where <NR> is the level of pid namespace and thus - the number of virtual pids in it. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- pid.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 56 insertions(+), 5 deletions(-) --- ./kernel/pid.c.ve10 2007-07-06 11:04:15.000000000 +0400 +++ ./kernel/pid.c 2007-07-06 11:04:48.000000000 +0400 @@ -32,7 +32,6 @@ #define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift) static struct hlist_head *pid_hash; static int pidhash_shift; -static struct kmem_cache *pid_cachep; struct pid init_struct_pid = INIT_STRUCT_PID; int pid_max = PID_MAX_DEFAULT; @@ -179,11 +178,15 @@ static int next_pidmap(struct pid_namesp fastcall void put_pid(struct pid *pid) { + struct pid_namespace *ns; + if (!pid) return; + + ns = pid->numbers[0].ns; if ((atomic_read(&pid->count) == 1) || atomic_dec_and_test(&pid->count)) - kmem_cache_free(pid_cachep, pid); + kmem_cache_free(ns->pid_cachep, pid); } EXPORT_SYMBOL_GPL(put_pid); @@ -212,7 +215,7 @@ struct pid *alloc_pid(struct pid_namespa enum pid_type type; int nr = -1; - pid = kmem_cache_alloc(pid_cachep, GFP_KERNEL); + pid = kmem_cache_alloc(init_pid_ns.pid_cachep, GFP_KERNEL); if (!pid) goto out; @@ -233,7 +236,7 @@ out: return pid; out_free: - kmem_cache_free(pid_cachep, pid); + kmem_cache_free(init_pid_ns.pid_cachep, pid); pid = NULL; goto out; } @@ -378,6 +381,52 @@ struct pid *find_ge_pid(int nr, struct p } EXPORT_SYMBOL_GPL(find_get_pid); +struct pid_cache { + int level; + char name[16]; + struct kmem_cache *cachep; + struct list_head lh; +}; + +static LIST_HEAD(pid_caches); +static DEFINE_MUTEX(pid_cache_mutex); + +static struct kmem_cache *create_pid_cachep(int level) +{ + struct pid_cache *pc; + struct kmem_cache *cachep = NULL; + + mutex_lock(&pid_cache_mutex); + list_for_each_entry …
creator: Pavel Emelianov
date: 2007-07-06T08:09:21-00:00

[PATCH 12/16] Reference counting of pid naspaces by pids
type: item
description: Getting and putting the pid namespace in alloc_pid() and free_pid() is too slow. Instead this I get/put the namespace by the pidmaps. When the pidmap allocates its first pid the namespace is get, when the pidmap becomes empty - the namespace is put. Although pids may live longer than their "fingerpints" in the pidmaps, this is ok to release the namespace with not yet freed struct pids, as this pid is not alive and no routines will use it. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- pid.c | 19 +++++++++++++++---- 1 files changed, 15 insertions(+), 4 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/kernel/pid.c linux-2.6.22-rc4-mm2-2/kernel/pid.c --- linux-2.6.22-rc4-mm2.orig/kernel/pid.c 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/kernel/pid.c 2007-07-04 19:00:38.000000000 +0400 @@ -89,16 +95,23 @@ static __cacheline_aligned_in_smp DEFIN static fastcall void free_pidmap(struct pid_namespace *pid_ns, int pid) { - struct pidmap *map = pid_ns->pidmap + pid / BITS_PER_PAGE; int offset = pid & BITS_PER_PAGE_MASK; + int map_id = pid / BITS_PER_PAGE; + struct pidmap *map = pid_ns->pidmap + map_id; + int free_pids; clear_bit(offset, map->page); - atomic_inc(&map->nr_free); + free_pids = atomic_inc_return(&map->nr_free); + + if (map_id == 0) + free_pids++; + if (free_pids == BITS_PER_PAGE) + put_pid_ns(pid_ns); } static int alloc_pidmap(struct pid_namespace *pid_ns) { - int i, offset, max_scan, pid, last = pid_ns->last_pid; + int i, offset, max_scan, pid, last = pid_ns->last_pid, free_pids; struct pidmap *map; pid = last + 1; @@ -126,7 +139,11 @@ static int alloc_pidmap(struct pid_names if (likely(atomic_read(&map->nr_free))) { do { if (!test_and_set_bit(offset, map->page)) { - atomic_dec(&map->nr_free); + free_pids = atomic_dec_return( + &map->nr_free); + if (free_pids == BITS_PER_PAGE - 1) + get_pid_ns(pid_ns); + pid_ns->last_pid = pid; return pid; } _______________________________________________ Containers mailing list Containers@lists.linux-f…
creator: Pavel Emelianov
date: 2007-07-06T08:10:06-00:00

[PATCH 13/16] Switch to operating with pid_numbers instead of pids
type: item
description: Make alloc_pid() initialize pid_numbers and hash them into the hashtable, not the struct pid itself. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- pid.c | 47 +++++++++++++++++++++++++++++++++-------------- 1 files changed, 33 insertions(+), 14 deletions(-) --- ./kernel/pid.c.ve12 2007-07-05 11:06:41.000000000 +0400 +++ ./kernel/pid.c 2007-07-05 11:08:23.000000000 +0400 @@ -28,8 +28,10 @@ #include <linux/hash.h> #include <linux/pid_namespace.h> #include <linux/init_task.h> +#include <linux/proc_fs.h> -#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift) +#define pid_hashfn(nr, ns) \ + hash_long((unsigned long)nr + (unsigned long)ns, pidhash_shift) static struct hlist_head *pid_hash; static int pidhash_shift; struct pid init_struct_pid = INIT_STRUCT_PID; @@ -194,7 +198,7 @@ fastcall void put_pid(struct pid *pid) if (!pid) return; - ns = pid->numbers[0].ns; + ns = pid->numbers[pid->level].ns; if ((atomic_read(&pid->count) == 1) || atomic_dec_and_test(&pid->count)) kmem_cache_free(ns->pid_cachep, pid); @@ -210,13 +214,17 @@ static void delayed_put_pid(struct rcu_h fastcall void free_pid(struct pid *pid) { /* We can be called with write_lock_irq(&tasklist_lock) held */ + int i; unsigned long flags; spin_lock_irqsave(&pidmap_lock, flags); - hlist_del_rcu(&pid->pid_chain); + for (i = 0; i <= pid->level; i++) + hlist_del_rcu(&pid->numbers[i].pid_chain); spin_unlock_irqrestore(&pidmap_lock, flags); - free_pidmap(&init_pid_ns, pid->nr); + for (i = 0; i <= pid->level; i++) + free_pidmap(pid->numbers[i].ns, pid->numbers[i].nr); + call_rcu(&pid->rcu, delayed_put_pid); } @@ -224,30 +232,43 @@ struct pid *alloc_pid(struct pid_namespa { struct pid *pid; enum pid_type type; - int nr = -1; + struct pid_namespace *ns; + int i, nr; - pid = kmem_cache_alloc(init_pid_ns.pid_cachep, GFP_KERNEL); + pid = kmem_cache_alloc(pid_ns->pid_cachep, GFP_KERNEL); if (!pid) goto out; - nr = alloc_pidmap(current->nsproxy->pid_ns); - if (nr < 0) - goto out_free; + ns = pid_ns; + f…
creator: Pavel Emelianov
date: 2007-07-06T08:10:47-00:00

[PATCH 14/16] Make pid namespaces clonnable
type: item
description: Just add the support for cloning pid namespaces. Note that the namespace is destroyed via schedule_work(). This is done so, since the namespace will put the proc_mnt and thus may fall asleep. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- include/linux/pid_namespace.h | 5 +- include/linux/sched.h | 1 kernel/fork.c | 26 ++++++++--- kernel/nsproxy.c | 2 kernel/pid.c | 96 ++++++++++++++++++++++++++++++++++++++++-- 5 files changed, 118 insertions(+), 12 deletions(-) --- ./include/linux/pid_namespace.h.ve13 2007-07-06 11:05:05.000000000 +0400 +++ ./include/linux/pid_namespace.h 2007-07-06 11:05:05.000000000 +0400 @@ -15,7 +15,10 @@ struct pidmap { #define PIDMAP_ENTRIES ((PID_MAX_LIMIT + 8*PAGE_SIZE - 1)/PAGE_SIZE/8) struct pid_namespace { - struct kref kref; + union { + struct kref kref; + struct work_struct free_work; + }; struct pidmap pidmap[PIDMAP_ENTRIES]; int last_pid; int level; --- ./include/linux/sched.h.ve13 2007-07-06 11:05:05.000000000 +0400 +++ ./include/linux/sched.h 2007-07-06 11:05:23.000000000 +0400 @@ -26,6 +26,7 @@ #define CLONE_NEWUTS 0x04000000 /* New utsname group? */ #define CLONE_NEWIPC 0x08000000 /* New ipcs */ #define CLONE_NEWUSER 0x10000000 /* New user namespace */ +#define CLONE_NEWPIDS 0x20000000 /* New pids */ /* * Scheduling policies --- ./kernel/fork.c.ve13 2007-07-06 11:05:05.000000000 +0400 +++ ./kernel/fork.c 2007-07-06 11:05:05.000000000 +0400 @@ -1267,11 +1267,22 @@ static struct task_struct *copy_process( __ptrace_link(p, current->parent); if (thread_group_leader(p)) { - p->signal->tty = current->signal->tty; - p->signal->pgrp = task_pgrp_nr(current); - set_task_session(p, task_session_nr(current)); - attach_pid(p, PIDTYPE_PGID, task_pgrp(current)); - attach_pid(p, PIDTYPE_SID, task_session(current)); + if (clone_flags & CLONE_NEWPIDS) { + p->nsproxy->pid_ns->child_reaper = p; + p->signal->tty = NULL; + p->signal->pgrp = p->pid; + set_task_session(p, p->pid); + attach_pid(p, PIDTYPE_PGID, pid); + attach_pid(p, PIDTYPE_SID, p…
creator: Pavel Emelianov
date: 2007-07-06T08:11:18-00:00

[PATCH 15/16] Changes to show virtual ids to user
type: item
description: This is the largest patch in the set. Make all (I hope) the places where the pid is shown to or get from user operate on the virtual pids. The idea is: - all in-kernel data structures must store either struct pid itself or the pid's global nr, obtained with pid_nr() call; - when seeking the task from kernel code with the stored id one should use find_task_by_pid() call that works with global pids; - when showing pid's numerical value to the user the virtual one should be used, but however when one shows task's pid outside this task's namespace the global one is to be used; - when getting the pid from userspace one need to consider this as the virtual one and use appropriate task/pid-searching functions. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- arch/ia64/kernel/signal.c | 4 ++-- arch/parisc/kernel/signal.c | 2 +- drivers/char/tty_io.c | 7 ++++--- fs/binfmt_elf.c | 16 ++++++++-------- fs/binfmt_elf_fdpic.c | 16 ++++++++-------- fs/exec.c | 4 ++-- fs/proc/array.c | 21 ++++++++++++++------- fs/proc/base.c | 37 +++++++++++++++++++++++-------------- include/net/scm.h | 4 +++- ipc/mqueue.c | 4 +++- ipc/msg.c | 6 +++--- ipc/sem.c | 8 ++++---- ipc/shm.c | 6 +++--- kernel/capability.c | 13 ++++++++----- kernel/exit.c | 31 ++++++++++++++++++++----------- kernel/fork.c | 2 +- kernel/futex.c | 20 +++++++++++--------- kernel/ptrace.c | 4 +++- kernel/sched.c | 3 ++- kernel/signal.c | 26 +++++++++++++++++--------- kernel/sys.c | 38 +++++++++++++++++++++++--------------- kernel/timer.c | 7 ++++--- net/core/scm.c | 4 +++- net/unix/af_unix.c | 6 +++--- 24 files changed, 173 insertions(+), 116 deletions(-) --- ./arch/ia64/kernel/signal.c.ve14 2007-05-29 13:34:03.000000000 +0400 +++ ./arch/ia64/kernel/signal.c 2007-07-06 11:07:04.000000000 +0400 @@ -227,7 +227,7 @@ ia64_rt_sigreturn (struct sigscratch *sc si.si_signo = SIGSEGV; si.si_errno = 0; si.si_code = SI_KERNEL; - si.si_pid = current->pid; + si.si_pid = task_pid_vnr(current); si.si_uid = current->uid; si.si_addr = sc;…
creator: Pavel Emelianov
date: 2007-07-06T08:13:20-00:00

[PATCH 16/16] Remove already unneeded memners from struct pid
type: item
description: Since we've switched from using these we may just remove them. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- init_task.h | 3 --- pid.h | 3 --- 2 files changed, 6 deletions(-) diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 @@ -40,9 +40,6 @@ enum pid_type struct pid { atomic_t count; - /* Try to keep pid_chain in the same cacheline as nr for find_pid */ - int nr; - struct hlist_node pid_chain; /* lists of tasks that use this pid */ struct hlist_head tasks[PIDTYPE_MAX]; struct rcu_head rcu; diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/init_task.h linux-2.6.22-rc4-mm2-2/include/linux/init_task.h --- linux-2.6.22-rc4-mm2.orig/include/linux/init_task.h 2007-06-14 12:14:29.000000000 +0400 +++ linux-2.6.22-rc4-mm2-2/include/linux/init_task.h 2007-07-04 19:00:38.000000000 +0400 @@ -91,9 +91,6 @@ extern struct group_info init_groups; #define INIT_STRUCT_PID { \ .count = ATOMIC_INIT(1), \ - .nr = 0, \ - /* Don't put this struct pid in pid_hash */ \ - .pid_chain = { .next = NULL, .pprev = NULL }, \ .tasks = { \ { .first = &init_task.pids[PIDTYPE_PID].node }, \ { .first = &init_task.pids[PIDTYPE_PGID].node }, \ _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-06T08:16:29-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote: > This is "submition for inclusion" of hierarchical, not kconfig > configurable, zero overheaded ;) pid namespaces. > > The overall idea is the following: > > The namespace are organized as a tree - once a task is cloned > with CLONE_NEWPIDS (yes, I've also switched to it :) the new > namespace becomes the parent's child and tasks living in the > parent namespace see the tasks from the new one. The numerical > ids are used on the kernel-user boundary, i.e. when we export > pid to user we show the id, that should be used to address the > task in question from the namespace we're exporting this id to. how does that behave when: a) the parent dies and gets reaped? b) the 'spawned' init dies, but other tasks inside the pid space are still active? c) what visibility rules do apply for the various spaces (including the default host space)? > The main difference from Suka's patches are the following: > > 0. Suka's patches change the kernel/pid.c code too heavy. > This set keeps the kernel code look like it was without > the patches. However, this is a minor issue. The major is: > > 1. Suka's approach is to remove the notion of the task's > numerical pid from the kernel at all. The numbers are > used on the kernel-user boundary or within the kernel but > with the namespace this nr belongs to. This results in > massive changes of struct's members fro int pid to struct > pid *pid, task->pid becomes the virtual id and so on and > so forth. > My approach is to keep the good old logic in the kernel. > The task->pid is a global and unique pid, find_pid() finds > the pid by its global id and so on. The virtual ids appear > on the user-kernel boundary only. Thus drivers and other > kernel code may still be unaware of pids unless they do not > communicate with the userspace and get/put numerical pids. interesting ... not sure that is what kernel folks have in mind though (IIRC, the struct pid change was considered a ke…
creator: Herbert Poetzl
date: 2007-07-09T12:02:36-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Herbert Poetzl wrote: > On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote: >> This is "submition for inclusion" of hierarchical, not kconfig >> configurable, zero overheaded ;) pid namespaces. >> >> The overall idea is the following: >> >> The namespace are organized as a tree - once a task is cloned >> with CLONE_NEWPIDS (yes, I've also switched to it :) the new >> namespace becomes the parent's child and tasks living in the >> parent namespace see the tasks from the new one. The numerical >> ids are used on the kernel-user boundary, i.e. when we export >> pid to user we show the id, that should be used to address the >> task in question from the namespace we're exporting this id to. > > how does that behave when: > > a) the parent dies and gets reaped? The children are re-parented to the namespace's init. Surprised? > b) the 'spawned' init dies, but other tasks > inside the pid space are still active? The init's init becomes the namespace's init. > c) what visibility rules do apply for the > various spaces (including the default host space)? Each task sees tasks from its namespace and all its children namespaces. Yes, each task can see itself as well ;) >> The main difference from Suka's patches are the following: >> >> 0. Suka's patches change the kernel/pid.c code too heavy. >> This set keeps the kernel code look like it was without >> the patches. However, this is a minor issue. The major is: >> >> 1. Suka's approach is to remove the notion of the task's >> numerical pid from the kernel at all. The numbers are >> used on the kernel-user boundary or within the kernel but >> with the namespace this nr belongs to. This results in >> massive changes of struct's members fro int pid to struct >> pid *pid, task->pid becomes the virtual id and so on and >> so forth. >> My approach is to keep the good old logic in the kernel. >> The task->pid is a global and unique pid, find_pid() finds >> the pid by its global id and so on. The virtual ids appear >> on th…
creator: Pavel Emelianov
date: 2007-07-09T13:16:17-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: > This is "submition for inclusion" of hierarchical, not kconfig > configurable, zero overheaded ;) pid namespaces. Not able to boot my ppc64 machine with the patchset :( Thanks, Badari Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc000000000247ce0 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=32 NUMA pSeries Modules linked in: NIP: c000000000247ce0 LR: c000000000107bf4 CTR: c000000000107bd0 REGS: c0000000005fb920 TRAP: 0300 Not tainted (2.6.22-rc6-mm1) MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000048 XER: 20000005 DAR: 0000000000000000, DSISR: 0000000040000000 TASK = c000000000514650[0] 'swapper' THREAD: c0000000005f8000 CPU: 0 GPR00: c0000000000bd42c c0000000005fbba0 c0000000005f8f18 0000000000000000 GPR04: 0000000000000000 c000000000645190 c00000000d025000 c00000000d024cb8 GPR08: c00000000d024d10 0000000000000000 c00000000d024cf0 0000000000000000 GPR12: 000000000000247f c000000000514d80 0000000000000000 c00000000044e438 GPR16: 4000000001c00000 c00000000044ce50 0000000000000000 0000000000000000 GPR20: c0000000004f9fd0 00000000020f9fd0 0000000000000000 c0000000005bc370 GPR24: c0000000005bc2f8 c000000000539738 0000000002000000 0000000000000000 GPR28: c00000000d024c00 0000000000000000 c00000000054a358 c00000000d024c00 NIP [c000000000247ce0] .kref_get+0x0/0x28 LR [c000000000107bf4] .proc_set_super+0x24/0x54 Call Trace: [c0000000005fbba0] [c0000000005fbc30] 0xc0000000005fbc30 (unreliable) [c0000000005fbc30] [c0000000000bd42c] .sget+0x34c/0x470 [c0000000005fbd00] [c000000000107da4] .proc_get_sb+0xa0/0x18c [c0000000005fbdb0] [c0000000000bdc84] .vfs_kern_mount+0x80/0xe8 [c0000000005fbe50] [c0000000004ea1e4] .proc_root_init+0x4c/0x158 [c0000000005fbed0] [c0000000004cb9ec] .start_kernel+0x3c8/0x404 [c0000000005fbf90] [c000000000008524] .start_here_common+0x54/0x130 Instruction dump: 60000000 e8440008 7c0903a6 4e800421 e8410028 38000001 38210080 7c030…
creator: Badari Pulavarty
date: 2007-07-09T17:46:20-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Mon, Jul 09, 2007 at 05:16:17PM +0400, Pavel Emelianov wrote: > Herbert Poetzl wrote: > > On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote: > >> This is "submition for inclusion" of hierarchical, not kconfig > >> configurable, zero overheaded ;) pid namespaces. > >> > >> The overall idea is the following: > >> > >> The namespace are organized as a tree - once a task is cloned > >> with CLONE_NEWPIDS (yes, I've also switched to it :) the new > >> namespace becomes the parent's child and tasks living in the > >> parent namespace see the tasks from the new one. The numerical > >> ids are used on the kernel-user boundary, i.e. when we export > >> pid to user we show the id, that should be used to address the > >> task in question from the namespace we're exporting this id to. > > > > how does that behave when: > > > > a) the parent dies and gets reaped? > > The children are re-parented to the namespace's init. > Surprised? > > > b) the 'spawned' init dies, but other tasks > > inside the pid space are still active? > > The init's init becomes the namespace's init. so an init from the parent process is chosen here? or 'the init' process? or what am I missing here? > > c) what visibility rules do apply for the > > various spaces (including the default host space)? > > Each task sees tasks from its namespace and all its children > namespaces. Yes, each task can see itself as well ;) > > >> The main difference from Suka's patches are the following: > >> > >> 0. Suka's patches change the kernel/pid.c code too heavy. > >> This set keeps the kernel code look like it was without > >> the patches. However, this is a minor issue. The major is: > >> > >> 1. Suka's approach is to remove the notion of the task's > >> numerical pid from the kernel at all. The numbers are > >> used on the kernel-user boundary or within the kernel but > >> with the namespace this nr belongs to. This results in > >> massive changes of struct's members fro int pid to struct > >> pid *pid…
creator: Herbert Poetzl
date: 2007-07-09T19:52:41-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Badari Pulavarty wrote: > On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: >> This is "submition for inclusion" of hierarchical, not kconfig >> configurable, zero overheaded ;) pid namespaces. > > Not able to boot my ppc64 machine with the patchset :( I can't boot either on a x86_64 but I don't even have logs to send :( C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-07-09T20:06:24-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: >>>> 3. Suka assumes that pid namespace can live without proc mount >>>> and tries to make the code work with pid_ns->proc_mnt change >>>> from NULL to not-NULL from times to times. >>>> My code calls the kern_mount() at the namespace creation and >>>> thus the pid_namespace always works with proc. >>> shouldn't that be done by userspace instead? >> It can be. But when the namespace is being created there's no >> any userspace in it yet. > > I'm not talking about the 'userspace inside the space' > I'm talking about the userspace creating the space > (what if I do not want to have any proc mount?) yes, can't we let the user doing the unshare or clone decide whether it needs to mount /proc or not in the new pid namespace ? that's already optional on the host. C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-07-09T20:12:01-00:00

Re: [PATCH 1/16] Round up the API
type: item
description: Pavel Emelianov wrote: > The set of functions process_session, task_session, process_group > and task_pgrp is confusing, as the names can be mixed with each other > when looking at the code for a long time. > > The proposals are to > * equip the functions that return the integer with _nr suffix to > represent that fact, > * and to make all functions work with task (not process) by making > the common prefix of the same name. > > For monotony the routines signal_session() and set_signal_session() > are replaced with task_session_nr() and set_task_session(), especially > since they are only used with the explicit task->signal dereference. > > Signed-off-by: Pavel Emelianov <xemul@openvz.org> > Acked-by: Serge E. Hallyn <serue@us.ibm.com> please let's get that one in. I think we are all ok with it. right ? C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-07-09T20:18:33-00:00

Re: [PATCH 2/16] Miscelaneous preparations for namespaces
type: item
description: Pavel Emelianov wrote: > The most importaint change is moving exit_task_namespaces() > inside exit_notify() to makes it possible to notify the > exiting task's parent. However this should be done before > release_task() to address the issue pointed by Sukadev with > NFS kernel thread. Have you actually checked that doing an unshare() with a NFS mount ? > Other changes are small and do not deserve separate description. yes. if they were in a separate patch, you could push them to -mm. thanks, C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-07-09T20:22:13-00:00

Re: [PATCH 4/16] Change data structures for pid namespaces
type: item
description: Pavel Emelianov wrote: > struct pid_namespace will have the kmem_cache to allocate > the pids from, the parent, as they are hierarchical, and > the level of nesting value. > > struct pid will have a variable length array of pid_number-s > one for each namespace this pid lives in. The level value > shows the level of the namespace this pid lives in and thus - > the number of elements in the numbers array. > > Signed-off-by: Pavel Emelianov <xemul@openvz.org> > > --- > > include/linux/init_task.h | 6 ++++++ > include/linux/pid.h | 9 +++++++++ > include/linux/pid_namespace.h | 3 +++ > kernel/pid.c | 3 ++- > 4 files changed, 20 insertions(+), 1 deletion(-) > > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 > +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 > @@ -40,6 +40,13 @@ enum pid_type > * processes. > */ > > +struct pid_number { > + /* Try to keep pid_chain in the same cacheline as nr for find_pid */ > + int nr; > + struct pid_namespace *ns; > + struct hlist_node pid_chain; > +}; > + > struct pid > { > atomic_t count; > @@ -40,6 +40,8 @@ enum pid_type > /* lists of tasks that use this pid */ > struct hlist_head tasks[PIDTYPE_MAX]; > struct rcu_head rcu; > + int level; > + struct pid_number numbers[1]; > }; > > extern struct pid init_struct_pid; > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h 2007-06-14 12:14:29.000000000 +0400 > +++ linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h 2007-07-04 19:00:39.000000000 +0400 > @@ -16,7 +15,10 @@ struct pidmap { > struct kref kref; > struct pidmap pidmap[PIDMAP_ENTRIES]; > int last_pid; > + int level; > struct task_struct *child_reaper; > + struct kmem_cache *pid_cachep; so, that looks like a good idea to have the ca…
creator: Cedric Le Goater
date: 2007-07-09T20:25:41-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | This is "submition for inclusion" of hierarchical, not kconfig | configurable, zero overheaded ;) pid namespaces. | | The overall idea is the following: | | The namespace are organized as a tree - once a task is cloned | with CLONE_NEWPIDS (yes, I've also switched to it :) the new | namespace becomes the parent's child and tasks living in the | parent namespace see the tasks from the new one. The numerical | ids are used on the kernel-user boundary, i.e. when we export | pid to user we show the id, that should be used to address the | task in question from the namespace we're exporting this id to. | | The main difference from Suka's patches are the following: | | 0. Suka's patches change the kernel/pid.c code too heavy. | This set keeps the kernel code look like it was without | the patches. However, this is a minor issue. The major is: | | 1. Suka's approach is to remove the notion of the task's | numerical pid from the kernel at all. The numbers are | used on the kernel-user boundary or within the kernel but | with the namespace this nr belongs to. This results in | massive changes of struct's members fro int pid to struct | pid *pid, task->pid becomes the virtual id and so on and | so forth. Your basic design is similar to what our patchset has been for a while, with a few changes. My patchset does not remove the task->pid. It still uses it with the caveat that with multiple namespaces it is not unique. getpid() implementation does not changes for instance. Basically our patchset has init_pid_ns as the last element in the pid->numbers[] array while yours is having it as the first. How big a difference it makes, I am not sure. | | My approach is to keep the good old logic in the kernel. | The task->pid is a global and unique pid, find_pid() finds | the pid by its global id and so on. The virtual ids appear | on the user-kernel boundary only. Thus drivers and other | kernel code may still be unaware of pids unless they do…
creator: Sukadev Bhattiprolu
date: 2007-07-09T21:42:44-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Mon, 2007-07-09 at 22:06 +0200, Cedric Le Goater wrote: > Badari Pulavarty wrote: > > On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: > >> This is "submition for inclusion" of hierarchical, not kconfig > >> configurable, zero overheaded ;) pid namespaces. > > > > Not able to boot my ppc64 machine with the patchset :( > > I can't boot either on a x86_64 but I don't even have logs to send :( Yes. It blew up way early in the boot on my x86_64, so nothing came up on the console to capture (blank screen) :( Thanks, Badari _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Badari Pulavarty
date: 2007-07-09T23:00:34-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | This is "submition for inclusion" of hierarchical, not kconfig | configurable, zero overheaded ;) pid namespaces. | | The overall idea is the following: | | The namespace are organized as a tree - once a task is cloned | with CLONE_NEWPIDS (yes, I've also switched to it :) the new Can you really clone() a pid namespace all by itself ? copy_namespaces() has the following: if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER))) return 0; doesn't it mean you cannot create a pid namespace using clone() unless one of the above flags are also specified ? unshare_nsproxy_namespaces() has the following correct check: if (!(unshare_flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER | CLONE_NEWPIDS))) return 0; BTW, why not use CLONE_NEWPID and drop the 'S' ? We don't have 'S' with other namespaces. Suka _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2007-07-10T00:29:29-00:00

Re: [PATCH 7/16] Helpers to find the task by its numerical ids
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | When searching the task by numerical id on may need to find | it using global pid (as it is done now in kernel) or by its | virtual id, e.g. when sending a signal to a task from one | namespace the sender will specify the task's virtual id. | | Signed-off-by: Pavel Emelianov <xemul@openvz.org> | | --- | | fs/proc/base.c | 2 +- | include/linux/pid.h | 13 +++++++++++-- | include/linux/sched.h | 31 +++++++++++++++++++++++++++++-- | kernel/pid.c | 32 +++++++++++++++++--------------- | 4 files changed, 58 insertions(+), 20 deletions(-) | | --- ./fs/proc/base.c.ve6 2007-07-06 10:58:56.000000000 +0400 | +++ ./fs/proc/base.c 2007-07-06 11:03:41.000000000 +0400 | @@ -2230,7 +2230,7 @@ static struct task_struct *next_tgid(uns | rcu_read_lock(); | retry: | task = NULL; | - pid = find_ge_pid(tgid); | + pid = find_ge_pid(tgid, &init_pid_ns); | if (pid) { | tgid = pid->nr + 1; | task = pid_task(pid, PIDTYPE_PID); | --- ./include/linux/pid.h.ve6 2007-07-06 11:03:27.000000000 +0400 | +++ ./include/linux/pid.h 2007-07-06 11:03:27.000000000 +0400 | @@ -98,14 +98,23 @@ extern struct pid_namespace init_pid_ns; | /* | * look up a PID in the hash table. Must be called with the tasklist_lock | * or rcu_read_lock() held. | + * | + * find_pid_ns() finds the pid in the namespace specified | + * find_pid() find the pid by its global id, i.e. in the init namespace | + * find_vpid() finr the pid by its virtual id, i.e. in the current namespace | + * | + * see also find_task_by_pid() set in include/linux/sched.h | */ | -extern struct pid *FASTCALL(find_pid(int nr)); | +extern struct pid *FASTCALL(find_pid_ns(int nr, struct pid_namespace *ns)); | + | +#define find_vpid(pid) find_pid_ns(pid, current->nsproxy->pid_ns) | +#define find_pid(pid) find_pid_ns(pid, &init_pid_ns) Adding a second interface maybe more confusing to drivers and non-pid users. But more importantly, modifying find_pid() to refer to only init_pid_ns would require auditing existing find…
creator: Sukadev Bhattiprolu
date: 2007-07-10T04:00:45-00:00

Re: [PATCH 8/16] Masquerade the siginfo when sending a pid to a foreign namespace
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | When user send signal from (say) init namespace to any task in a sub | namespace the siginfo struct must not carry the sender's pid value, as | this value may refer to some task in the destination namespace and thus | may confuse the application. Also, do you prevent signals to the child reaper of a container from within its container ? If so, can you show me where you handle it ? I can't seem to find it. And I guess you do allow signals to the child-reaper of a container from its parent container. | | The consensus was to pretend in this case as if it is the kernel who | sends the signal. | | The pid_ns_accessible() call is introduced to check this pid-to-ns | accessibility. | | Signed-off-by: Pavel Emelianov <xemul@openvz.org> | | --- | | include/linux/pid.h | 10 ++++++++++ | kernel/signal.c | 34 ++++++++++++++++++++++++++++------ | 2 files changed, 38 insertions(+), 6 deletions(-) | | diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h | --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 | +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 | @@ -83,6 +89,16 @@ extern void FASTCALL(detach_pid(struct t | return nr; | } | | +/* | + * checks whether the pid actually lives in the namespace ns, i.e. it was | + * created in this namespace or it was moved there. | + */ | + | +static inline int pid_ns_accessible(struct pid_namespace *ns, struct pid *pid) | +{ | + return pid->numbers[pid->level].ns == ns; | +} | + | #define do_each_pid_task(pid, type, task) \ | do { \ | struct hlist_node *pos___; \ | diff -upr linux-2.6.22-rc4-mm2.orig/kernel/signal.c linux-2.6.22-rc4-mm2-2/kernel/signal.c | --- linux-2.6.22-rc4-mm2.orig/kernel/signal.c 2007-07-04 19:00:38.000000000 +0400 | +++ linux-2.6.22-rc4-mm2-2/kernel/signal.c 2007-07-04 19:00:38.000000000 +0400 | @@ -1124,13 +1124,31 @@ EXPORT_SYMBOL_GPL(kill_pid_info_as_uid); …
creator: Sukadev Bhattiprolu
date: 2007-07-10T04:18:00-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: I am not able to find a specific patch that this might be in, but what happens when the child-reaper of a container exits ? Do you terminate all processes in the container ? I thought that was discussed earlier and the consensus was to terminate all processes in that container and its subordinate containers. Is that not the case now ? Suka Pavel Emelianov [xemul@openvz.org] wrote: | This is "submition for inclusion" of hierarchical, not kconfig | configurable, zero overheaded ;) pid namespaces. | | The overall idea is the following: | | The namespace are organized as a tree - once a task is cloned | with CLONE_NEWPIDS (yes, I've also switched to it :) the new | namespace becomes the parent's child and tasks living in the | parent namespace see the tasks from the new one. The numerical | ids are used on the kernel-user boundary, i.e. when we export | pid to user we show the id, that should be used to address the | task in question from the namespace we're exporting this id to. | | The main difference from Suka's patches are the following: | | 0. Suka's patches change the kernel/pid.c code too heavy. | This set keeps the kernel code look like it was without | the patches. However, this is a minor issue. The major is: | | 1. Suka's approach is to remove the notion of the task's | numerical pid from the kernel at all. The numbers are | used on the kernel-user boundary or within the kernel but | with the namespace this nr belongs to. This results in | massive changes of struct's members fro int pid to struct | pid *pid, task->pid becomes the virtual id and so on and | so forth. | My approach is to keep the good old logic in the kernel. | The task->pid is a global and unique pid, find_pid() finds | the pid by its global id and so on. The virtual ids appear | on the user-kernel boundary only. Thus drivers and other | kernel code may still be unaware of pids unless they do not | communicate with the userspace and get/put numerical pids. | | And some more minor differences: …
creator: Sukadev Bhattiprolu
date: 2007-07-10T04:26:19-00:00

Re: [PATCH 4/16] Change data structures for pid namespaces
type: item
description: Cedric Le Goater [clg@fr.ibm.com] wrote: | Pavel Emelianov wrote: | > struct pid_namespace will have the kmem_cache to allocate | > the pids from, the parent, as they are hierarchical, and | > the level of nesting value. | > | > struct pid will have a variable length array of pid_number-s | > one for each namespace this pid lives in. The level value | > shows the level of the namespace this pid lives in and thus - | > the number of elements in the numbers array. | > | > Signed-off-by: Pavel Emelianov <xemul@openvz.org> | > | > --- | > | > include/linux/init_task.h | 6 ++++++ | > include/linux/pid.h | 9 +++++++++ | > include/linux/pid_namespace.h | 3 +++ | > kernel/pid.c | 3 ++- | > 4 files changed, 20 insertions(+), 1 deletion(-) | > | > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h | > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 | > +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 | > @@ -40,6 +40,13 @@ enum pid_type | > * processes. | > */ | > | > +struct pid_number { | > + /* Try to keep pid_chain in the same cacheline as nr for find_pid */ | > + int nr; | > + struct pid_namespace *ns; | > + struct hlist_node pid_chain; | > +}; We meant to go back and look at removing the extra 'struct pid *' we had here. Looks like you did that. Cool. | > + | > struct pid | > { | > atomic_t count; | > @@ -40,6 +40,8 @@ enum pid_type | > /* lists of tasks that use this pid */ | > struct hlist_head tasks[PIDTYPE_MAX]; | > struct rcu_head rcu; | > + int level; | > + struct pid_number numbers[1]; | > }; | > | > extern struct pid init_struct_pid; | > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h | > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h 2007-06-14 12:14:29.000000000 +0400 | > +++ linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h 2007-07-04 19:00:39.000000000 +0…
creator: Sukadev Bhattiprolu
date: 2007-07-10T04:32:50-00:00

Re: [PATCH 6/16] Helpers to obtain pid numbers
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | When showing pid to user or getting the pid numerical id for in-kernel | use the value of this id may differ depending on the namespace. | | This set of helpers is used to get the global pid nr, the virtual (i.e. | seen by task in its namespace) nr and the nr as it is seen from the | specified namespace. | | Signed-off-by: Pavel Emelianov <xemul@openvz.org> | | --- | | include/linux/pid.h | 27 ++++++++++++ | include/linux/sched.h | 108 +++++++++++++++++++++++++++++++++++++++++++++----- | kernel/pid.c | 8 +++ | 3 files changed, 132 insertions(+), 11 deletions(-) | | diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h | --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 | +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 | @@ -83,6 +89,9 @@ extern void FASTCALL(detach_pid(struct t | extern void FASTCALL(transfer_pid(struct task_struct *old, | struct task_struct *new, enum pid_type)); | | +struct pid_namespace; | +extern struct pid_namespace init_pid_ns; | + | /* | * look up a PID in the hash table. Must be called with the tasklist_lock | * or rcu_read_lock() held. | @@ -93,14 +99,36 @@ extern void FASTCALL(detach_pid(struct t | extern struct pid *alloc_pid(void); | extern void FASTCALL(free_pid(struct pid *pid)); | | +/* | + * the helpers to get the pid's id seen from different namespaces | + * | + * pid_nr() : global id, i.e. the id seen from the init namespace; | + * pid_vnr() : virtual id, i.e. the id seen from the namespace this pid | + * belongs to. this only makes sence when called in the | + * context of the task that belongs to the same namespace; | + * pid_nr_ns() : id seen from the ns specified. | + * | + * see also task_xid_nr() etc in include/linux/sched.h | + */ I think its a bit confusing and error-prone to have both pid_nr() and pid_vnr(). BTW, shouldn't you use pid_vnr() in do_task_stat() ? You c…
creator: Sukadev Bhattiprolu
date: 2007-07-10T05:18:01-00:00

Re: [PATCH 1/16] Round up the API
type: item
description: Cedric Le Goater wrote: > Pavel Emelianov wrote: >> The set of functions process_session, task_session, process_group >> and task_pgrp is confusing, as the names can be mixed with each other >> when looking at the code for a long time. >> >> The proposals are to >> * equip the functions that return the integer with _nr suffix to >> represent that fact, >> * and to make all functions work with task (not process) by making >> the common prefix of the same name. >> >> For monotony the routines signal_session() and set_signal_session() >> are replaced with task_session_nr() and set_task_session(), especially >> since they are only used with the explicit task->signal dereference. >> >> Signed-off-by: Pavel Emelianov <xemul@openvz.org> >> Acked-by: Serge E. Hallyn <serue@us.ibm.com> > > please let's get that one in. > > I think we are all ok with it. right ? Right. That's already the 3rd time I send it to Andrew... > C. > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T06:40:13-00:00

Re: [PATCH 2/16] Miscelaneous preparations for namespaces
type: item
description: Cedric Le Goater wrote: > Pavel Emelianov wrote: >> The most importaint change is moving exit_task_namespaces() >> inside exit_notify() to makes it possible to notify the >> exiting task's parent. However this should be done before >> release_task() to address the issue pointed by Sukadev with >> NFS kernel thread. > > Have you actually checked that doing an unshare() with a NFS mount ? Not unshare(), but clone(). I admit that I lost smth significant, but everything was fine... >> Other changes are small and do not deserve separate description. > > yes. if they were in a separate patch, you could push them to -mm. OK > thanks, > > C. > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T06:42:09-00:00

Re: [PATCH 7/16] Helpers to find the task by its numerical ids
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | When searching the task by numerical id on may need to find > | it using global pid (as it is done now in kernel) or by its > | virtual id, e.g. when sending a signal to a task from one > | namespace the sender will specify the task's virtual id. > | > | Signed-off-by: Pavel Emelianov <xemul@openvz.org> > | > | --- > | > | fs/proc/base.c | 2 +- > | include/linux/pid.h | 13 +++++++++++-- > | include/linux/sched.h | 31 +++++++++++++++++++++++++++++-- > | kernel/pid.c | 32 +++++++++++++++++--------------- > | 4 files changed, 58 insertions(+), 20 deletions(-) > | > | --- ./fs/proc/base.c.ve6 2007-07-06 10:58:56.000000000 +0400 > | +++ ./fs/proc/base.c 2007-07-06 11:03:41.000000000 +0400 > | @@ -2230,7 +2230,7 @@ static struct task_struct *next_tgid(uns > | rcu_read_lock(); > | retry: > | task = NULL; > | - pid = find_ge_pid(tgid); > | + pid = find_ge_pid(tgid, &init_pid_ns); > | if (pid) { > | tgid = pid->nr + 1; > | task = pid_task(pid, PIDTYPE_PID); > | --- ./include/linux/pid.h.ve6 2007-07-06 11:03:27.000000000 +0400 > | +++ ./include/linux/pid.h 2007-07-06 11:03:27.000000000 +0400 > | @@ -98,14 +98,23 @@ extern struct pid_namespace init_pid_ns; > | /* > | * look up a PID in the hash table. Must be called with the tasklist_lock > | * or rcu_read_lock() held. > | + * > | + * find_pid_ns() finds the pid in the namespace specified > | + * find_pid() find the pid by its global id, i.e. in the init namespace > | + * find_vpid() finr the pid by its virtual id, i.e. in the current namespace > | + * > | + * see also find_task_by_pid() set in include/linux/sched.h > | */ > | -extern struct pid *FASTCALL(find_pid(int nr)); > | +extern struct pid *FASTCALL(find_pid_ns(int nr, struct pid_namespace *ns)); > | + > | +#define find_vpid(pid) find_pid_ns(pid, current->nsproxy->pid_ns) > | +#define find_pid(pid) find_pid_ns(pid, &init_pid_ns) > > Adding a second interface maybe more confusing to drivers and non…
creator: Pavel Emelianov
date: 2007-07-10T06:47:09-00:00

Re: [PATCH 6/16] Helpers to obtain pid numbers
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | When showing pid to user or getting the pid numerical id for in-kernel > | use the value of this id may differ depending on the namespace. > | > | This set of helpers is used to get the global pid nr, the virtual (i.e. > | seen by task in its namespace) nr and the nr as it is seen from the > | specified namespace. > | > | Signed-off-by: Pavel Emelianov <xemul@openvz.org> > | > | --- > | > | include/linux/pid.h | 27 ++++++++++++ > | include/linux/sched.h | 108 +++++++++++++++++++++++++++++++++++++++++++++----- > | kernel/pid.c | 8 +++ > | 3 files changed, 132 insertions(+), 11 deletions(-) > | > | diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h > | --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 > | +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 > | @@ -83,6 +89,9 @@ extern void FASTCALL(detach_pid(struct t > | extern void FASTCALL(transfer_pid(struct task_struct *old, > | struct task_struct *new, enum pid_type)); > | > | +struct pid_namespace; > | +extern struct pid_namespace init_pid_ns; > | + > | /* > | * look up a PID in the hash table. Must be called with the tasklist_lock > | * or rcu_read_lock() held. > | @@ -93,14 +99,36 @@ extern void FASTCALL(detach_pid(struct t > | extern struct pid *alloc_pid(void); > | extern void FASTCALL(free_pid(struct pid *pid)); > | > | +/* > | + * the helpers to get the pid's id seen from different namespaces > | + * > | + * pid_nr() : global id, i.e. the id seen from the init namespace; > | + * pid_vnr() : virtual id, i.e. the id seen from the namespace this pid > | + * belongs to. this only makes sence when called in the > | + * context of the task that belongs to the same namespace; > | + * pid_nr_ns() : id seen from the ns specified. > | + * > | + * see also task_xid_nr() etc in include/linux/sched.h > | + */ > > I think its a bit c…
creator: Pavel Emelianov
date: 2007-07-10T06:49:58-00:00

Re: [PATCH 8/16] Masquerade the siginfo when sending a pid to a foreign namespace
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | When user send signal from (say) init namespace to any task in a sub > | namespace the siginfo struct must not carry the sender's pid value, as > | this value may refer to some task in the destination namespace and thus > | may confuse the application. > > Also, do you prevent signals to the child reaper of a container from within > its container ? If so, can you show me where you handle it ? I can't > seem to find it. > > And I guess you do allow signals to the child-reaper of a container from > its parent container. See my comment below. > | > | The consensus was to pretend in this case as if it is the kernel who > | sends the signal. > | > | The pid_ns_accessible() call is introduced to check this pid-to-ns > | accessibility. > | > | Signed-off-by: Pavel Emelianov <xemul@openvz.org> > | > | --- > | > | include/linux/pid.h | 10 ++++++++++ > | kernel/signal.c | 34 ++++++++++++++++++++++++++++------ > | 2 files changed, 38 insertions(+), 6 deletions(-) > | > | diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h > | --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 > | +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 > | @@ -83,6 +89,16 @@ extern void FASTCALL(detach_pid(struct t > | return nr; > | } > | > | +/* > | + * checks whether the pid actually lives in the namespace ns, i.e. it was > | + * created in this namespace or it was moved there. > | + */ > | + > | +static inline int pid_ns_accessible(struct pid_namespace *ns, struct pid *pid) > | +{ > | + return pid->numbers[pid->level].ns == ns; > | +} > | + > | #define do_each_pid_task(pid, type, task) \ > | do { \ > | struct hlist_node *pos___; \ > | diff -upr linux-2.6.22-rc4-mm2.orig/kernel/signal.c linux-2.6.22-rc4-mm2-2/kernel/signal.c > | --- linux-2.6.22-rc4-mm2.orig/kernel/signal.c 2007-07-04 19:00:38.000000000 +0400 > …
creator: Pavel Emelianov
date: 2007-07-10T06:56:14-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Cedric Le Goater wrote: >>>>> 3. Suka assumes that pid namespace can live without proc mount >>>>> and tries to make the code work with pid_ns->proc_mnt change >>>>> from NULL to not-NULL from times to times. >>>>> My code calls the kern_mount() at the namespace creation and >>>>> thus the pid_namespace always works with proc. >>>> shouldn't that be done by userspace instead? >>> It can be. But when the namespace is being created there's no >>> any userspace in it yet. >> I'm not talking about the 'userspace inside the space' >> I'm talking about the userspace creating the space >> (what if I do not want to have any proc mount?) > > yes, can't we let the user doing the unshare or clone decide whether > it needs to mount /proc or not in the new pid namespace ? > > that's already optional on the host. If we admit that the pid_ns->proc_mnt pointer can change from NULL to some valid mount, then we should track all the possible races with its dereference in the code. We have already caught one of such "tricky" places with Suka's patches and sent the OOPs to him. My opinion is that having kern_mount-ed proc makes no discomfort but protects from all the possible races with this pointer dereferencing. Thanks, Pavel > C. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T06:59:35-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: sukadev@us.ibm.com wrote: > I am not able to find a specific patch that this might be in, > but what happens when the child-reaper of a container exits ? The init namespace's init becomes this init's namespace's init :) In other words: if (unlikely(tsk == child_reaper(tsk))) { if (tsk->nsproxy->pid_ns != &init_pid_ns) tsk->nsproxy->pid_ns->child_reaper = init_pid_ns.child_reaper; else panic("Attempted to kill init!"); } > Do you terminate all processes in the container ? I thought > that was discussed earlier and the consensus was to terminate > all processes in that container and its subordinate containers. > > Is that not the case now ? That's the case, but this code works without this change. We can do it later. > Suka > > Pavel Emelianov [xemul@openvz.org] wrote: > | This is "submition for inclusion" of hierarchical, not kconfig > | configurable, zero overheaded ;) pid namespaces. > | > | The overall idea is the following: > | > | The namespace are organized as a tree - once a task is cloned > | with CLONE_NEWPIDS (yes, I've also switched to it :) the new > | namespace becomes the parent's child and tasks living in the > | parent namespace see the tasks from the new one. The numerical > | ids are used on the kernel-user boundary, i.e. when we export > | pid to user we show the id, that should be used to address the > | task in question from the namespace we're exporting this id to. > | > | The main difference from Suka's patches are the following: > | > | 0. Suka's patches change the kernel/pid.c code too heavy. > | This set keeps the kernel code look like it was without > | the patches. However, this is a minor issue. The major is: > | > | 1. Suka's approach is to remove the notion of the task's > | numerical pid from the kernel at all. The numbers are > | used on the kernel-user boundary or within the kernel but > | with the namespace this nr belongs to. This results in > | massive changes of struct's members fro int pid to struct > | pid *pid, task->pid becom…
creator: Pavel Emelianov
date: 2007-07-10T07:02:51-00:00

Re: [PATCH 4/16] Change data structures for pid namespaces
type: item
description: sukadev@us.ibm.com wrote: > Cedric Le Goater [clg@fr.ibm.com] wrote: > | Pavel Emelianov wrote: > | > struct pid_namespace will have the kmem_cache to allocate > | > the pids from, the parent, as they are hierarchical, and > | > the level of nesting value. > | > > | > struct pid will have a variable length array of pid_number-s > | > one for each namespace this pid lives in. The level value > | > shows the level of the namespace this pid lives in and thus - > | > the number of elements in the numbers array. > | > > | > Signed-off-by: Pavel Emelianov <xemul@openvz.org> > | > > | > --- > | > > | > include/linux/init_task.h | 6 ++++++ > | > include/linux/pid.h | 9 +++++++++ > | > include/linux/pid_namespace.h | 3 +++ > | > kernel/pid.c | 3 ++- > | > 4 files changed, 20 insertions(+), 1 deletion(-) > | > > | > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h linux-2.6.22-rc4-mm2-2/include/linux/pid.h > | > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14 12:14:29.000000000 +0400 > | > +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04 19:00:38.000000000 +0400 > | > @@ -40,6 +40,13 @@ enum pid_type > | > * processes. > | > */ > | > > | > +struct pid_number { > | > + /* Try to keep pid_chain in the same cacheline as nr for find_pid */ > | > + int nr; > | > + struct pid_namespace *ns; > | > + struct hlist_node pid_chain; > | > +}; > > We meant to go back and look at removing the extra 'struct pid *' we had > here. Looks like you did that. Cool. > > | > + > | > struct pid > | > { > | > atomic_t count; > | > @@ -40,6 +40,8 @@ enum pid_type > | > /* lists of tasks that use this pid */ > | > struct hlist_head tasks[PIDTYPE_MAX]; > | > struct rcu_head rcu; > | > + int level; > | > + struct pid_number numbers[1]; > | > }; > | > > | > extern struct pid init_struct_pid; > | > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h > | > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace…
creator: Pavel Emelianov
date: 2007-07-10T07:04:09-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Badari Pulavarty wrote: > On Mon, 2007-07-09 at 22:06 +0200, Cedric Le Goater wrote: >> Badari Pulavarty wrote: >>> On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: >>>> This is "submition for inclusion" of hierarchical, not kconfig >>>> configurable, zero overheaded ;) pid namespaces. >>> Not able to boot my ppc64 machine with the patchset :( >> I can't boot either on a x86_64 but I don't even have logs to send :( > > Yes. It blew up way early in the boot on my x86_64, so nothing came > up on the console to capture (blank screen) :( That's bad news... I will re-check for it. It seems to me that I lost some parts during the patch splitting... :( > Thanks, > Badari > > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T07:05:18-00:00

Re: [PATCH 1/16] Round up the API
type: item
description: On Tue, 10 Jul 2007 10:40:13 +0400 Pavel Emelianov <xemul@openvz.org> wrote: > > I think we are all ok with it. right ? > > Right. That's already the 3rd time I send it to Andrew... I'm basically ignoring all the containers/resource-control stuff, waiting for it to appear to have settled down. It's quite unclear which patches are at the RFC stage and which are at the ready-to-go stage. If you guys could gather and maintain the acked-by's and make it clear what the maturity level is on each patch series it would help, thanks. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: akpm
date: 2007-07-10T07:34:50-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | This is "submition for inclusion" of hierarchical, not kconfig > | configurable, zero overheaded ;) pid namespaces. > | > | The overall idea is the following: > | > | The namespace are organized as a tree - once a task is cloned > | with CLONE_NEWPIDS (yes, I've also switched to it :) the new > > Can you really clone() a pid namespace all by itself ? > copy_namespaces() has the following: > > > if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER))) > return 0; > > doesn't it mean you cannot create a pid namespace using clone() unless > one of the above flags are also specified ? > > unshare_nsproxy_namespaces() has the following correct check: > > if (!(unshare_flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | > CLONE_NEWUSER | CLONE_NEWPIDS))) > return 0; I have already pointed this out. I attached the previous version of this patch where I cloned the namespaces via unshare :( However the copy_pid_ns code looks correct. I will resend it altogether. My bad. I have to stop working at times I want to sleep... > BTW, why not use CLONE_NEWPID and drop the 'S' ? We don't have 'S' with > other namespaces. CLONE_NEWPID? Hm... I see no difference. OK I'll switch to it. > Suka > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T09:41:16-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Cedric Le Goater wrote: > Badari Pulavarty wrote: >> On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: >>> This is "submition for inclusion" of hierarchical, not kconfig >>> configurable, zero overheaded ;) pid namespaces. >> Not able to boot my ppc64 machine with the patchset :( > > I can't boot either on a x86_64 but I don't even have logs to send :( Neither can I. And I cannot boot clean 2.6.22-rc6-mm1 either :( Does someone already know what the reason is? > C. > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T11:30:16-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Pavel Emelianov wrote: > Cedric Le Goater wrote: >> Badari Pulavarty wrote: >>> On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: >>>> This is "submition for inclusion" of hierarchical, not kconfig >>>> configurable, zero overheaded ;) pid namespaces. >>> Not able to boot my ppc64 machine with the patchset :( >> I can't boot either on a x86_64 but I don't even have logs to send :( Did you tryed to append at the kernel command line the parameter: earlyprintk=serial,ttyS0,keep > > Neither can I. And I cannot boot clean 2.6.22-rc6-mm1 either :( > Does someone already know what the reason is? > >> C. >> > > _______________________________________________ > Containers mailing list > Containers@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daniel Lezcano
date: 2007-07-10T12:05:08-00:00

Re: [PATCH 4/16] Change data structures for pid namespaces
type: item
description: >> | > + >> | > struct pid >> | > { >> | > atomic_t count; >> | > @@ -40,6 +40,8 @@ enum pid_type >> | > /* lists of tasks that use this pid */ >> | > struct hlist_head tasks[PIDTYPE_MAX]; >> | > struct rcu_head rcu; >> | > + int level; >> | > + struct pid_number numbers[1]; >> | > }; >> | > >> | > extern struct pid init_struct_pid; >> | > diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h >> | > --- linux-2.6.22-rc4-mm2.orig/include/linux/pid_namespace.h 2007-06-14 12:14:29.000000000 +0400 >> | > +++ linux-2.6.22-rc4-mm2-2/include/linux/pid_namespace.h 2007-07-04 19:00:39.000000000 +0400 >> | > @@ -16,7 +15,10 @@ struct pidmap { >> | > struct kref kref; >> | > struct pidmap pidmap[PIDMAP_ENTRIES]; >> | > int last_pid; >> | > + int level; >> | > struct task_struct *child_reaper; >> | > + struct kmem_cache *pid_cachep; >> | >> | so, that looks like a good idea to have the cache in the pidmap. could you >> | push that independently to see how it all fits together ? >> >> Yes. I like this idea too. > > OK. I will collect the patches you Acked and send them to Andrew independently. good thanks, however that part on the *pid_cachep will require some rework on your patchset. C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-07-10T12:07:45-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Daniel Lezcano wrote: > Pavel Emelianov wrote: >> Cedric Le Goater wrote: >>> Badari Pulavarty wrote: >>>> On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: >>>>> This is "submition for inclusion" of hierarchical, not kconfig >>>>> configurable, zero overheaded ;) pid namespaces. >>>> Not able to boot my ppc64 machine with the patchset :( >>> I can't boot either on a x86_64 but I don't even have logs to send :( > > Did you tryed to append at the kernel command line the parameter: > > earlyprintk=serial,ttyS0,keep I have already faced the problem, thanks :) The bad-guy is CONFIG_DMAR. I'll talk to intel developers about this :) And a couple of patches to fix proc (I'll send them in a moment). i386 works without is and all the others crash. Kirill explained me why. It looks like a big problem for i386. He told, that during the boot first 32MiBs of memory are mapped and thus all NULL pointer dereferences succeed. Is it good? Thanks, Pavel >> >> Neither can I. And I cannot boot clean 2.6.22-rc6-mm1 either :( >> Does someone already know what the reason is? >> >>> C. >>> >> >> _______________________________________________ >> Containers mailing list >> Containers@lists.linux-foundation.org >> https://lists.linux-foundation.org/mailman/listinfo/containers > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T13:03:13-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: > Not able to boot my ppc64 machine with the patchset :( > > Thanks, > Badari That's the hunk lost during the split: --- ./fs/proc/root.c.procfix 2007-07-10 13:52:08.000000000 +0400 +++ ./fs/proc/root.c 2007-07-10 15:23:20.000000000 +0400 @@ -111,7 +111,7 @@ void __init proc_root_init(void) err = register_filesystem(&proc_fs_type); if (err) return; - proc_mnt = kern_mount(&proc_fs_type); + proc_mnt = kern_mount_data(&proc_fs_type, &init_pid_ns); err = PTR_ERR(proc_mnt); if (IS_ERR(proc_mnt)) { unregister_filesystem(&proc_fs_type); With this machine should boot fine. Thanks, Pavel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-10T13:06:08-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | This is "submition for inclusion" of hierarchical, not kconfig > | configurable, zero overheaded ;) pid namespaces. > | > | The overall idea is the following: > | > | The namespace are organized as a tree - once a task is cloned > | with CLONE_NEWPIDS (yes, I've also switched to it :) the new > > Can you really clone() a pid namespace all by itself ? > copy_namespaces() has the following: > > > if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER))) > return 0; > > doesn't it mean you cannot create a pid namespace using clone() unless > one of the above flags are also specified ? > > unshare_nsproxy_namespaces() has the following correct check: > > if (!(unshare_flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | > CLONE_NEWUSER | CLONE_NEWPIDS))) > return 0; I have lost a couple of hunks when I splitted the patch :( That's the correct version, cap_set fix and the renamed CLONE_ flag. --- ./include/linux/sched.h.fix 2007-07-06 11:09:33.000000000 +0400 +++ ./include/linux/sched.h 2007-07-10 13:48:19.000000000 +0400 @@ -26,7 +26,7 @@ #define CLONE_NEWUTS 0x04000000 /* New utsname group? */ #define CLONE_NEWIPC 0x08000000 /* New ipcs */ #define CLONE_NEWUSER 0x10000000 /* New user namespace */ -#define CLONE_NEWPIDS 0x20000000 /* New pids */ +#define CLONE_NEWPID 0x20000000 /* New pids */ /* * Scheduling policies --- ./kernel/capability.c.fix 2007-07-06 11:09:33.000000000 +0400 +++ ./kernel/capability.c 2007-07-10 13:50:16.000000000 +0400 @@ -103,7 +103,7 @@ static inline int cap_set_pg(int pgrp_nr int found = 0; struct pid *pgrp; - pgrp = find_pid(pgrp_nr); + pgrp = find_pid_ns(pgrp_nr, current->nsproxy->pid_ns); do_each_pid_task(pgrp, PIDTYPE_PGID, g) { target = g; while_each_thread(g, target) { --- ./kernel/fork.c.fix 2007-07-06 11:09:33.000000000 +0400 +++ ./kernel/fork.c 2007-07-10 13:48:13.000000000 +0400 @@ -1267,7 +1267,7 @@ static struct task_struct *copy_process( __…
creator: Pavel Emelianov
date: 2007-07-10T13:08:42-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Tue, 2007-07-10 at 17:06 +0400, Pavel Emelianov wrote: > > Not able to boot my ppc64 machine with the patchset :( > > > > Thanks, > > Badari > > That's the hunk lost during the split: > > --- ./fs/proc/root.c.procfix 2007-07-10 13:52:08.000000000 +0400 > +++ ./fs/proc/root.c 2007-07-10 15:23:20.000000000 +0400 > @@ -111,7 +111,7 @@ void __init proc_root_init(void) > err = register_filesystem(&proc_fs_type); > if (err) > return; > - proc_mnt = kern_mount(&proc_fs_type); > + proc_mnt = kern_mount_data(&proc_fs_type, &init_pid_ns); > err = PTR_ERR(proc_mnt); > if (IS_ERR(proc_mnt)) { > unregister_filesystem(&proc_fs_type); > > > With this machine should boot fine. Yes. My ppc64 box booted fine with this patch. Thanks, Badari _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Badari Pulavarty
date: 2007-07-10T20:33:14-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Tue, 2007-07-10 at 15:30 +0400, Pavel Emelianov wrote: > Cedric Le Goater wrote: > > Badari Pulavarty wrote: > >> On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote: > >>> This is "submition for inclusion" of hierarchical, not kconfig > >>> configurable, zero overheaded ;) pid namespaces. > >> Not able to boot my ppc64 machine with the patchset :( > > > > I can't boot either on a x86_64 but I don't even have logs to send :( > > Neither can I. And I cannot boot clean 2.6.22-rc6-mm1 either :( > Does someone already know what the reason is? 2.6.22-rc6-mm1 boots fine on my x86-64 machine. your patches with the fix (in fs/proc/root.c), I am able to boot my x86-64 machine also. Thanks, Badari _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Badari Pulavarty
date: 2007-07-10T20:34:16-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote: > This is "submition for inclusion" of hierarchical, not kconfig > configurable, zero overheaded ;) pid namespaces. How big is it? Do I want it on my cell phone or on my wireless router? -- Mathematics is the supreme nostalgia of our time. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Matt Mackall
date: 2007-07-11T01:16:52-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Matt Mackall wrote: > On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote: >> This is "submition for inclusion" of hierarchical, not kconfig >> configurable, zero overheaded ;) pid namespaces. > > How big is it? Summary: 50 files changed, 877 insertions, 241 deletions. Besides, each patch has a diffstat output in the letter. > Do I want it on my cell phone or on my wireless router? > I do not know, but those who do not need the namespaces at all won't even notice its presence. I tried to do such. Pavel. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2007-07-11T06:39:02-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Wed, Jul 11, 2007 at 10:39:02AM +0400, Pavel Emelianov wrote: > Matt Mackall wrote: > > On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote: > >> This is "submition for inclusion" of hierarchical, not kconfig > >> configurable, zero overheaded ;) pid namespaces. > > > > How big is it? > > Summary: 50 files changed, 877 insertions, 241 deletions. Besides, > each patch has a diffstat output in the letter. No, how much impact does it have on the compiled kernel's size? > > Do I want it on my cell phone or on my wireless router? > > I do not know, but those who do not need the namespaces at > all won't even notice its presence. I tried to do such. It seems likely that something that adds a net 600 lines of code will have a noticeable footprint. -- Mathematics is the supreme nostalgia of our time. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Matt Mackall
date: 2007-07-11T15:14:42-00:00

Re: [PATCH 10/16] Changes in copy_process() to work with pid namespaces
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | We must pass the namespace pointer to the alloc_pid() to | show what namespace to allocate the pid from and we should | call this *after* the namespace is copied. | | Essentially, the task->pid etc initialization is done after | the alloc_pid(). | | To do so I move the alloc_pid() inside copy_process() and | introduce an argument to the alloc_pid() function. | | Signed-off-by: Pavel Emelianov <xemul@openvz.org> | | --- | | include/linux/pid.h | 2 +- | kernel/fork.c | 29 +++++++++++++++++------------ | kernel/pid.c | 2 +- | 3 files changed, 19 insertions(+), 14 deletions(-) | | --- ./include/linux/pid.h.ve9 2007-07-06 11:03:55.000000000 +0400 | +++ ./include/linux/pid.h 2007-07-06 11:03:55.000000000 +0400 | @@ -116,7 +116,7 @@ extern struct pid *FASTCALL(find_pid_ns( | extern struct pid *find_get_pid(int nr); | extern struct pid *find_ge_pid(int nr, struct pid_namespace *); | | -extern struct pid *alloc_pid(void); | +extern struct pid *alloc_pid(struct pid_namespace *ns); | extern void FASTCALL(free_pid(struct pid *pid)); | | /* | --- ./kernel/fork.c.ve9 2007-07-06 11:03:55.000000000 +0400 | +++ ./kernel/fork.c 2007-07-06 11:04:07.000000000 +0400 | @@ -50,6 +50,7 @@ | #include <linux/taskstats_kern.h> | #include <linux/random.h> | #include <linux/tty.h> | +#include <linux/pid.h> | | #include <asm/pgtable.h> | #include <asm/pgalloc.h> | @@ -1032,7 +1033,6 @@ static struct task_struct *copy_process( | p->did_exec = 0; | delayacct_tsk_init(p); /* Must remain after dup_task_struct() */ | copy_flags(clone_flags, p); | - p->pid = pid_nr(pid); | INIT_LIST_HEAD(&p->children); | INIT_LIST_HEAD(&p->sibling); | p->vfork_done = NULL; | @@ -1107,10 +1107,6 @@ static struct task_struct *copy_process( | p->blocked_on = NULL; /* not blocked yet */ | #endif | | - p->tgid = p->pid; | - if (clone_flags & CLONE_THREAD) | - p->tgid = current->tgid; | - | if ((retval = security_task_alloc(p))) | goto bad_fork_cleanup_policy; | if ((retval = audi…
creator: Sukadev Bhattiprolu
date: 2007-07-12T00:21:02-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | sukadev@us.ibm.com wrote: | > Pavel Emelianov [xemul@openvz.org] wrote: | > | This is "submition for inclusion" of hierarchical, not kconfig | > | configurable, zero overheaded ;) pid namespaces. | > | | > | The overall idea is the following: | > | | > | The namespace are organized as a tree - once a task is cloned | > | with CLONE_NEWPIDS (yes, I've also switched to it :) the new | > | > Can you really clone() a pid namespace all by itself ? | > copy_namespaces() has the following: | > | > | > if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER))) | > return 0; | > | > doesn't it mean you cannot create a pid namespace using clone() unless | > one of the above flags are also specified ? | > | > unshare_nsproxy_namespaces() has the following correct check: | > | > if (!(unshare_flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | | > CLONE_NEWUSER | CLONE_NEWPIDS))) | > return 0; | | I have lost a couple of hunks when I splitted the patch :( | That's the correct version, cap_set fix and the renamed CLONE_ flag. | | --- ./include/linux/sched.h.fix 2007-07-06 11:09:33.000000000 +0400 | +++ ./include/linux/sched.h 2007-07-10 13:48:19.000000000 +0400 | @@ -26,7 +26,7 @@ | #define CLONE_NEWUTS 0x04000000 /* New utsname group? */ | #define CLONE_NEWIPC 0x08000000 /* New ipcs */ | #define CLONE_NEWUSER 0x10000000 /* New user namespace */ | -#define CLONE_NEWPIDS 0x20000000 /* New pids */ | +#define CLONE_NEWPID 0x20000000 /* New pids */ | | /* | * Scheduling policies | --- ./kernel/capability.c.fix 2007-07-06 11:09:33.000000000 +0400 | +++ ./kernel/capability.c 2007-07-10 13:50:16.000000000 +0400 | @@ -103,7 +103,7 @@ static inline int cap_set_pg(int pgrp_nr | int found = 0; | struct pid *pgrp; | | - pgrp = find_pid(pgrp_nr); | + pgrp = find_pid_ns(pgrp_nr, current->nsproxy->pid_ns); | do_each_pid_task(pgrp, PIDTYPE_PGID, g) { | target = g; | while_each_thread(g, target) { | --- ./kernel/fork.c.fix 2007-07-06 …
creator: Sukadev Bhattiprolu
date: 2007-07-12T03:19:37-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: On Wed, 2007-07-11 at 20:19 -0700, sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | sukadev@us.ibm.com wrote: > |.. > My x86_64 system boots fine but crashes as below, when I run my > 'pidns_exec' test with a simple program that prints getpid(), getppid() > etc of the process in the child pid ns. > > Pls see > > http://www.geocities.com/sukadevb/Pidspace/2.6.22-rc6-mm1-pavel-1.tgz > > for the patches I currently have applied and let me know if I need more > on top. > > And see > > http://www.geocities.com/sukadevb/Pidspace/Test1/ > > for the test programs. You may need to run the 'mypid-loop.x' script > to repro the crash. The pidns_exec.c program calls clone() with CLONE_NEWPID > and execs the given program (it was included in Patch 0 of the patchset I > posted to Containers). > > Suka > > login: Unable to handle kernel NULL pointer dereference at 00000000000002fc RIP: Yes. I am noticing different set of problems on my ppc64 with above tests and patchset. Thanks, Badari Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns Not cloning container for unused subsystem ns ------------[ cut here ]------------ kernel BUG at kernel/workqueue.c:258! Oops: Exception in kernel mode, sig: 5 [#11] SMP NR_CPUS=32 NUMA pSeries Modules linked in: NIP: c000000000062e6c LR: c000000000062e54 CTR: 0000000000000000 REGS: c00000000d157af0 TRAP: 0700 Tainted: G D (2.6.22-rc6-mm1) MSR: 8000000000029032 <EE,ME,IR,DR> CR: 24000084 XER: 2000000f TASK = c00000000d0f7460[33] 'events/6' THREAD: c00000000d154000 CPU: 6 GPR00: 0000000000000001 c00000000d157d70 c00000000060fed8 0000000000000001 GPR04: c0000000005c2938 0000000000000000 c000000000064438 c00000000d005600 GPR08: c000000000684f20 7ffffffeffffffff …
creator: Badari Pulavarty
date: 2007-07-12T18:55:59-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: > My x86_64 system boots fine but crashes as below, when I run my > 'pidns_exec' test with a simple program that prints getpid(), getppid() > etc of the process in the child pid ns. > > Pls see > > http://www.geocities.com/sukadevb/Pidspace/2.6.22-rc6-mm1-pavel-1.tgz > > for the patches I currently have applied and let me know if I need more > on top. > > And see > > http://www.geocities.com/sukadevb/Pidspace/Test1/ > > for the test programs. You may need to run the 'mypid-loop.x' script > to repro the crash. The pidns_exec.c program calls clone() with CLONE_NEWPID > and execs the given program (it was included in Patch 0 of the patchset I > posted to Containers). > > Suka > > login: Unable to handle kernel NULL pointer dereference at 00000000000002fc RIP: > [<ffffffff802b9e5e>] proc_get_sb+0xfb/0x138 > PGD 104d53067 PUD 104d4d067 PMD 0 > Oops: 0002 [1] SMP > CPU 2 > Modules linked in: > Pid: 3279, comm: pidns_exec Not tainted 2.6.22-rc6-mm1-ovz1 #10 > RIP: 0010:[<ffffffff802b9e5e>] [<ffffffff802b9e5e>] proc_get_sb+0xfb/0x138 > RSP: 0018:ffff8101029d7d28 EFLAGS: 00010202 > RAX: ffff810100651840 RBX: ffff810104461400 RCX: ffff810100651878 > RDX: 0000000000000000 RSI: ffffffff806e5460 RDI: 0000000000000238 > RBP: ffff810102d886f8 R08: ffff810104461400 R09: ffff810100026000 > R10: 0000000000000000 R11: 0000000000000002 R12: ffff8101029c6000 > R13: 0000000002000000 R14: ffffffff806ee920 R15: ffff810102088cc0 > FS: 00002b0b499ec6f0(0000) GS:ffff81010069c3c0(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00000000000002fc CR3: 000000010381b000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process pidns_exec (pid: 3279, threadinfo ffff8101029d6000, task ffff81010269e7f0) > Stack: ffff810102088cc0 ffff810102088cc0 00000000fffffff4 ffffffff806ee920 > ffffffff8065f9d9 ffff8101029c6000 0000000002000000 ffffffff80287164 > 00000…
creator: Pavel Emelianov
date: 2007-07-16T08:47:10-00:00

Re: [PATCH 0/16] Pid namespaces
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | >My x86_64 system boots fine but crashes as below, when I run my | >'pidns_exec' test with a simple program that prints getpid(), getppid() | >etc of the process in the child pid ns. | > | >Pls see | > | >http://www.geocities.com/sukadevb/Pidspace/2.6.22-rc6-mm1-pavel-1.tgz | > | >for the patches I currently have applied and let me know if I need more | >on top. | > | >And see | > | >http://www.geocities.com/sukadevb/Pidspace/Test1/ | > | >for the test programs. You may need to run the 'mypid-loop.x' script | >to repro the crash. The pidns_exec.c program calls clone() with | >CLONE_NEWPID | >and execs the given program (it was included in Patch 0 of the patchset I | >posted to Containers). | > | >Suka | > | >login: Unable to handle kernel NULL pointer dereference at | >00000000000002fc RIP: | > [<ffffffff802b9e5e>] proc_get_sb+0xfb/0x138 | >PGD 104d53067 PUD 104d4d067 PMD 0 | >Oops: 0002 [1] SMP | >CPU 2 | >Modules linked in: | >Pid: 3279, comm: pidns_exec Not tainted 2.6.22-rc6-mm1-ovz1 #10 | >RIP: 0010:[<ffffffff802b9e5e>] [<ffffffff802b9e5e>] proc_get_sb+0xfb/0x138 | >RSP: 0018:ffff8101029d7d28 EFLAGS: 00010202 | >RAX: ffff810100651840 RBX: ffff810104461400 RCX: ffff810100651878 | >RDX: 0000000000000000 RSI: ffffffff806e5460 RDI: 0000000000000238 | >RBP: ffff810102d886f8 R08: ffff810104461400 R09: ffff810100026000 | >R10: 0000000000000000 R11: 0000000000000002 R12: ffff8101029c6000 | >R13: 0000000002000000 R14: ffffffff806ee920 R15: ffff810102088cc0 | >FS: 00002b0b499ec6f0(0000) GS:ffff81010069c3c0(0000) | >knlGS:0000000000000000 | >CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b | >CR2: 00000000000002fc CR3: 000000010381b000 CR4: 00000000000006e0 | >DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 | >DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 | >Process pidns_exec (pid: 3279, threadinfo ffff8101029d6000, task | >ffff81010269e7f0) | >Stack: ffff810102088cc0 ffff810102088cc0 00000…
creator: Sukadev Bhattiprolu
date: 2007-07-17T04:23:39-00:00

Re: [PATCH 13/16] Switch to operating with pid_numbers instead of pids
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | Make alloc_pid() initialize pid_numbers and hash them | into the hashtable, not the struct pid itself. | | Signed-off-by: Pavel Emelianov <xemul@openvz.org> | | --- | | pid.c | 47 +++++++++++++++++++++++++++++++++-------------- | 1 files changed, 33 insertions(+), 14 deletions(-) | | --- ./kernel/pid.c.ve12 2007-07-05 11:06:41.000000000 +0400 | +++ ./kernel/pid.c 2007-07-05 11:08:23.000000000 +0400 | @@ -28,8 +28,10 @@ | #include <linux/hash.h> | #include <linux/pid_namespace.h> | #include <linux/init_task.h> | +#include <linux/proc_fs.h> | | -#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift) | +#define pid_hashfn(nr, ns) \ | + hash_long((unsigned long)nr + (unsigned long)ns, pidhash_shift) | static struct hlist_head *pid_hash; | static int pidhash_shift; | struct pid init_struct_pid = INIT_STRUCT_PID; | @@ -194,7 +198,7 @@ fastcall void put_pid(struct pid *pid) | if (!pid) | return; | | - ns = pid->numbers[0].ns; | + ns = pid->numbers[pid->level].ns; | if ((atomic_read(&pid->count) == 1) || | atomic_dec_and_test(&pid->count)) | kmem_cache_free(ns->pid_cachep, pid); | @@ -210,13 +214,17 @@ static void delayed_put_pid(struct rcu_h | fastcall void free_pid(struct pid *pid) | { | /* We can be called with write_lock_irq(&tasklist_lock) held */ | + int i; | unsigned long flags; | | spin_lock_irqsave(&pidmap_lock, flags); | - hlist_del_rcu(&pid->pid_chain); | + for (i = 0; i <= pid->level; i++) | + hlist_del_rcu(&pid->numbers[i].pid_chain); | spin_unlock_irqrestore(&pidmap_lock, flags); | | - free_pidmap(&init_pid_ns, pid->nr); | + for (i = 0; i <= pid->level; i++) | + free_pidmap(pid->numbers[i].ns, pid->numbers[i].nr); | + | call_rcu(&pid->rcu, delayed_put_pid); | } | | @@ -224,30 +232,43 @@ struct pid *alloc_pid(struct pid_namespa | { | struct pid *pid; | enum pid_type type; | - int nr = -1; | + struct pid_namespace *ns; | + int i, nr; | | - pid = kmem_cache_alloc(init_pid_ns.pid_cachep, GFP_KERNEL); | + pid …
creator: Sukadev Bhattiprolu
date: 2007-07-25T00:36:19-00:00

Re: [PATCH 13/16] Switch to operating with pid_numbers instead of pids
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | Make alloc_pid() initialize pid_numbers and hash them > | into the hashtable, not the struct pid itself. > | > | Signed-off-by: Pavel Emelianov <xemul@openvz.org> > | > | --- > | > | pid.c | 47 +++++++++++++++++++++++++++++++++-------------- > | 1 files changed, 33 insertions(+), 14 deletions(-) > | > | --- ./kernel/pid.c.ve12 2007-07-05 11:06:41.000000000 +0400 > | +++ ./kernel/pid.c 2007-07-05 11:08:23.000000000 +0400 > | @@ -28,8 +28,10 @@ > | #include <linux/hash.h> > | #include <linux/pid_namespace.h> > | #include <linux/init_task.h> > | +#include <linux/proc_fs.h> > | > | -#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift) > | +#define pid_hashfn(nr, ns) \ > | + hash_long((unsigned long)nr + (unsigned long)ns, pidhash_shift) > | static struct hlist_head *pid_hash; > | static int pidhash_shift; > | struct pid init_struct_pid = INIT_STRUCT_PID; > | @@ -194,7 +198,7 @@ fastcall void put_pid(struct pid *pid) > | if (!pid) > | return; > | > | - ns = pid->numbers[0].ns; > | + ns = pid->numbers[pid->level].ns; > | if ((atomic_read(&pid->count) == 1) || > | atomic_dec_and_test(&pid->count)) > | kmem_cache_free(ns->pid_cachep, pid); > | @@ -210,13 +214,17 @@ static void delayed_put_pid(struct rcu_h > | fastcall void free_pid(struct pid *pid) > | { > | /* We can be called with write_lock_irq(&tasklist_lock) held */ > | + int i; > | unsigned long flags; > | > | spin_lock_irqsave(&pidmap_lock, flags); > | - hlist_del_rcu(&pid->pid_chain); > | + for (i = 0; i <= pid->level; i++) > | + hlist_del_rcu(&pid->numbers[i].pid_chain); > | spin_unlock_irqrestore(&pidmap_lock, flags); > | > | - free_pidmap(&init_pid_ns, pid->nr); > | + for (i = 0; i <= pid->level; i++) > | + free_pidmap(pid->numbers[i].ns, pid->numbers[i].nr); > | + > | call_rcu(&pid->rcu, delayed_put_pid); > | } > | > | @@ -224,30 +232,43 @@ struct pid *alloc_pid(struct pid_namespa > | { > | struct pid *pid; > | enum pid_type …
creator: Pavel Emelianov
date: 2007-07-25T10:07:04-00:00

Re: [PATCH 13/16] Switch to operating with pid_numbers instead of pids
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | sukadev@us.ibm.com wrote: | >Pavel Emelianov [xemul@openvz.org] wrote: | >| Make alloc_pid() initialize pid_numbers and hash them | >| into the hashtable, not the struct pid itself. | >| | >| Signed-off-by: Pavel Emelianov <xemul@openvz.org> | >| | >| --- | >| | >| pid.c | 47 +++++++++++++++++++++++++++++++++-------------- | >| 1 files changed, 33 insertions(+), 14 deletions(-) | >| | >| --- ./kernel/pid.c.ve12 2007-07-05 11:06:41.000000000 +0400 | >| +++ ./kernel/pid.c 2007-07-05 11:08:23.000000000 +0400 | >| @@ -28,8 +28,10 @@ | >| #include <linux/hash.h> | >| #include <linux/pid_namespace.h> | >| #include <linux/init_task.h> | >| +#include <linux/proc_fs.h> | >| | >| -#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift) | >| +#define pid_hashfn(nr, ns) \ | >| + hash_long((unsigned long)nr + (unsigned long)ns, pidhash_shift) | >| static struct hlist_head *pid_hash; | >| static int pidhash_shift; | >| struct pid init_struct_pid = INIT_STRUCT_PID; | >| @@ -194,7 +198,7 @@ fastcall void put_pid(struct pid *pid) | >| if (!pid) | >| return; | >| | >| - ns = pid->numbers[0].ns; | >| + ns = pid->numbers[pid->level].ns; | >| if ((atomic_read(&pid->count) == 1) || | >| atomic_dec_and_test(&pid->count)) | >| kmem_cache_free(ns->pid_cachep, pid); | >| @@ -210,13 +214,17 @@ static void delayed_put_pid(struct rcu_h | >| fastcall void free_pid(struct pid *pid) | >| { | >| /* We can be called with write_lock_irq(&tasklist_lock) held */ | >| + int i; | >| unsigned long flags; | >| | >| spin_lock_irqsave(&pidmap_lock, flags); | >| - hlist_del_rcu(&pid->pid_chain); | >| + for (i = 0; i <= pid->level; i++) | >| + hlist_del_rcu(&pid->numbers[i].pid_chain); | >| spin_unlock_irqrestore(&pidmap_lock, flags); | >| | >| - free_pidmap(&init_pid_ns, pid->nr); | >| + for (i = 0; i <= pid->level; i++) | >| + free_pidmap(pid->numbers[i].ns, pid->numbers[i].nr); | >| + | >| call_rcu(&pid->rcu, delayed_put_pid); | >| } | >| | >| @@ -224,3…
creator: Sukadev Bhattiprolu
date: 2007-07-25T19:13:34-00:00

Re: [PATCH 13/16] Switch to operating with pid_numbers instead of pids
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | sukadev@us.ibm.com wrote: > | >Pavel Emelianov [xemul@openvz.org] wrote: > | >| Make alloc_pid() initialize pid_numbers and hash them > | >| into the hashtable, not the struct pid itself. > | >| > | >| Signed-off-by: Pavel Emelianov <xemul@openvz.org> > | >| > | >| --- > | >| > | >| pid.c | 47 +++++++++++++++++++++++++++++++++-------------- > | >| 1 files changed, 33 insertions(+), 14 deletions(-) > | >| > | >| --- ./kernel/pid.c.ve12 2007-07-05 11:06:41.000000000 +0400 > | >| +++ ./kernel/pid.c 2007-07-05 11:08:23.000000000 +0400 > | >| @@ -28,8 +28,10 @@ > | >| #include <linux/hash.h> > | >| #include <linux/pid_namespace.h> > | >| #include <linux/init_task.h> > | >| +#include <linux/proc_fs.h> > | >| > | >| -#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift) > | >| +#define pid_hashfn(nr, ns) \ > | >| + hash_long((unsigned long)nr + (unsigned long)ns, pidhash_shift) > | >| static struct hlist_head *pid_hash; > | >| static int pidhash_shift; > | >| struct pid init_struct_pid = INIT_STRUCT_PID; > | >| @@ -194,7 +198,7 @@ fastcall void put_pid(struct pid *pid) > | >| if (!pid) > | >| return; > | >| > | >| - ns = pid->numbers[0].ns; > | >| + ns = pid->numbers[pid->level].ns; > | >| if ((atomic_read(&pid->count) == 1) || > | >| atomic_dec_and_test(&pid->count)) > | >| kmem_cache_free(ns->pid_cachep, pid); > | >| @@ -210,13 +214,17 @@ static void delayed_put_pid(struct rcu_h > | >| fastcall void free_pid(struct pid *pid) > | >| { > | >| /* We can be called with write_lock_irq(&tasklist_lock) held */ > | >| + int i; > | >| unsigned long flags; > | >| > | >| spin_lock_irqsave(&pidmap_lock, flags); > | >| - hlist_del_rcu(&pid->pid_chain); > | >| + for (i = 0; i <= pid->level; i++) > | >| + hlist_del_rcu(&pid->numbers[i].pid_chain); > | >| spin_unlock_irqrestore(&pidmap_lock, flags); > | >| > | >| - free_pidmap(&init_pid_ns, pid->nr); > | >| + for (i = 0; i <= pid->level; i++) > | >| +…
creator: Pavel Emelianov
date: 2007-07-26T06:42:22-00:00