OpenVZ Forum - RDF feed
type: channel
items: [RFC][PATCH 0/7] Clone PTS namespace
items: [RFC][PATCH 1/7]: Propagate error code from devpts_pty_new
items: [RFC][PATCH 2/7]: Factor out PTY index allocation
items: [RFC][PATCH 3/7]: Enable multiple mounts of /dev/pts
items: [RFC][PATCH 4/7]: Allow mknod of ptmx and tty in devpts
items: [RFC][PATCH 5/7]: Implement get_pts_ns() and put_pts_ns()
items: [RFC][PATCH 6/7]: Determine pts_ns from a pty's inode
items: [RFC][PATCH 7/7]: Enable cloning PTY namespaces
items: Re: [RFC][PATCH 0/7] Clone PTS namespace

[RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Devpts namespace patchset In continuation of the implementation of containers in mainline, we need to support multiple PTY namespaces so that the PTY index (ie the tty names) in one container is independent of the PTY indices of other containers. For instance this would allow each container to have a '/dev/pts/0' PTY and refer to different terminals. [PATCH 1/7]: Propagate error code from devpts_pty_new [PATCH 2/7]: Factor out PTY index allocation [PATCH 3/7]: Enable multiple mounts of /dev/pts [PATCH 4/7]: Allow mknod of ptmx and tty in devpts [PATCH 5/7]: Implement get_pts_ns() and put_pts_ns() [PATCH 6/7]: Determine pts_ns from a pty's inode [PATCH 7/7]: Enable cloning PTY namespaces Todo: - This patchset depends on availability of additional clone flags. and relies on on Cedric's clone64 patchset. See http://marc.info/?l=linux-kernel&m=120272411925609&w=2 - Needs some cleanup and more testing - Ensure patchset is bisect-safe --- Changelogs from earlier posts to Containers@. Changelog[v2]: (Patches 4 and 6 differ significantly from [v1]. Others are mostly the same) - [Alexey Dobriyan, Pavel Emelyanov] Removed the hack to check for user-space mount. - [Serge Hallyn] Added rcu locking around access to sb->s_fs_info. - [Serge Hallyn] Allow creation of /dev/pts/ptmx and /dev/pts/tty devices to simplify the process of finding the 'owning' pts-ns of the device (specially when accessed from parent-pts-ns) See patches 4 and 6 for details. Changelog[v1]: - Fixed circular reference by not caching the pts_ns in sb->s_fs_info (without incrementing reference count) and clearing the sb->s_fs_info when destroying the pts_ns - To allow access to a child container's ptys from parent container, determine the 'pts_ns' of a 'pty' from its inode. - Added a check (hack) to ensure user-space mount of /dev/pts is done before creating PTYs in a new pts-ns. - Reorganized the patchset and removed redundant changes. - Ported to work wih Cedric Le Goater's clone64() system call now that we a…
creator: Sukadev Bhattiprolu
date: 2008-04-08T21:53:33-00:00

[RFC][PATCH 1/7]: Propagate error code from devpts_pty_new
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 1/7]: Propagate error code from devpts_pty_new Have ptmx_open() propagate any error code returned by devpts_pty_new() (which returns either 0 or -ENOMEM anyway). Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- drivers/char/tty_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.25-rc8-mm1/drivers/char/tty_io.c =================================================================== --- 2.6.25-rc8-mm1.orig/drivers/char/tty_io.c 2008-04-07 14:49:56.000000000 -0700 +++ 2.6.25-rc8-mm1/drivers/char/tty_io.c 2008-04-08 09:12:55.000000000 -0700 @@ -2835,8 +2835,8 @@ static int ptmx_open(struct inode *inode filp->private_data = tty; file_move(filp, &tty->tty_files); - retval = -ENOMEM; - if (devpts_pty_new(tty->link)) + retval = devpts_pty_new(tty->link); + if (retval) goto out1; check_tty_count(tty, "tty_open"); _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-08T21:58:18-00:00

[RFC][PATCH 2/7]: Factor out PTY index allocation
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 2/7]: Factor out PTY index allocation Factor out the code used to allocate/free a pts index into new interfaces, devpts_new_index() and devpts_kill_index(). This localizes the external data structures used in managing the pts indices. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn<serue@us.ibm.com> Signed-off-by: Matt Helsley<matthltc@us.ibm.com> --- drivers/char/tty_io.c | 40 ++++++---------------------------------- fs/devpts/inode.c | 42 +++++++++++++++++++++++++++++++++++++++++- include/linux/devpts_fs.h | 4 ++++ 3 files changed, 51 insertions(+), 35 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:07.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:04:26.000000000 -0700 @@ -17,6 +17,8 @@ #ifdef CONFIG_UNIX98_PTYS +int devpts_new_index(void); +void devpts_kill_index(int idx); int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ struct tty_struct *devpts_get_tty(int number); /* get tty structure */ void devpts_pty_kill(int number); /* unlink */ @@ -24,6 +26,8 @@ void devpts_pty_kill(int number); /* u #else /* Dummy stubs in the no-pty case */ +static inline int devpts_new_index(void) { return -EINVAL; } +static inline void devpts_kill_index(int idx) { } static inline int devpts_pty_new(struct tty_struct *tty) { return -EINVAL; } static inline struct tty_struct *devpts_get_tty(int number) { return NULL; } static inline void devpts_pty_kill(int number) { } Index: 2.6.25-rc5-mm1/drivers/char/tty_io.c =================================================================== --- 2.6.25-rc5-mm1.orig/drivers/char/tty_io.c 2008-03-24 20:04:07.000000000 -0700 +++ 2.6.25-rc5-mm1/drivers/char/tty_io.c 2008-03-24 20:04:26.000000000 -0700 @@ -91,7 +91,6 @@ #include <linux/module.h> #include <linux…
creator: Sukadev Bhattiprolu
date: 2008-04-08T21:58:45-00:00

[RFC][PATCH 3/7]: Enable multiple mounts of /dev/pts
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject:[RFC][PATCH 3/7]: Enable multiple mounts of /dev/pts To support multiple PTY namespaces, we should be allow multiple mounts of /dev/pts, once within each PTY namespace. This patch removes the get_sb_single() in devpts_get_sb() and uses test and set sb interfaces to allow remounting /dev/pts. The patch also removes the globals, 'devpts_mnt', 'devpts_root' and uses a skeletal 'init_pts_ns' to store the vfsmount. Changelog [v3]: - Removed some unnecessary comments from devpts_set_sb() Changelog [v2]: - (Pavel Emelianov/Serge Hallyn) Remove reference to pts_ns from sb->s_fs_info to fix the circular reference (/dev/pts is not unmounted unless the pts_ns is destroyed, so we don't need a reference to the pts_ns). Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> --- fs/devpts/inode.c | 151 +++++++++++++++++++++++++++++++++++++--------- include/linux/devpts_fs.h | 11 +++ 2 files changed, 134 insertions(+), 28 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:26.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-04-01 18:08:42.000000000 -0700 @@ -14,6 +14,17 @@ #define _LINUX_DEVPTS_FS_H #include <linux/errno.h> +#include <linux/nsproxy.h> +#include <linux/kref.h> +#include <linux/idr.h> + +struct pts_namespace { + struct kref kref; + struct idr allocated_ptys; + struct vfsmount *mnt; +}; + +extern struct pts_namespace init_pts_ns; #ifdef CONFIG_UNIX98_PTYS Index: 2.6.25-rc5-mm1/fs/devpts/inode.c =================================================================== --- 2.6.25-rc5-mm1.orig/fs/devpts/inode.c 2008-03-24 20:04:26.000000000 -0700 +++ 2.6.25-rc5-mm1/fs/devpts/inode.c 2008-04-01 18:08:41.000000000 -0700 @@ -28,12 +28,8 @@ #define DEVPTS_DEFAULT_MODE 0600…
creator: Sukadev Bhattiprolu
date: 2008-04-08T21:59:09-00:00

[RFC][PATCH 4/7]: Allow mknod of ptmx and tty in devpts
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 4/7]: Allow mknod of ptmx and tty in devpts We want to allow administrators to access PTYs in descendant pts-namespaces, for instance "echo foo > /vserver/vserver1/dev/pts/0". To enable such access we must hold a reference to the pts-ns in which the device (ptmx or slave pty) exists. Note that we cannot use the pts-ns of the 'current' process since that pts-ns could be different from the pts-ns in which the PTY device was created. So we find the pts-ns from the inode of the PTY (inode->i_sb->s_fs_info). While this would work for the slave PTY devices like /dev/pts/0, it would not work for either the master PTY device (/dev/ptmx) or controlling terminal (/dev/tty). To uniformly handle the master, slave and controlling ttys, we allow creation of 'ptmx' and 'tty' devices in /dev/pts. When creating containers, the administrator can then: In init-pts-ns: $ mknod /dev/pts/ptmx c 5 2 $ mknod /dev/pts/tty c 5 0 $ rm /dev/ptmx /dev/tty $ ln -s /dev/pts/ptmx /dev/ptmx $ ln -s /dev/pts/tty /dev/tty In child-pts-ns: $ umount /dev/pts $ mount -t devpts lxcpts /dev/pts $ mknod /dev/pts/ptmx c 5 2 $ mknod /dev/pts/tty c 5 0 With this, even if the 'ptmx' is accessed from parent pts-ns we still find and hold the pts-ns in which 'ptmx' actually belongs. This patch merely allows creation of /dev/pts/ptmx and /dev/pts/tty. Follow-on patches will enable cloning the pts namespace and using the pts-ns from the inode. TODO: - Ability to unlink the /dev/pts/ptmx and /dev/pts/tty nodes. Note: - If /dev/ptmx is a symlink to /vserver/vserver1/dev/pts/ptmx, open("/dev/ptmx") in init-pts-ns will create a PTY in 'vserver1' ! Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- fs/devpts/inode.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 51 insertions(+), 4 deletions(-) Index: 2.6.25-rc8-mm1/fs/devpts/inode.c =================================================================== --- 2.6.25-rc8-…
creator: Sukadev Bhattiprolu
date: 2008-04-08T21:59:32-00:00

[RFC][PATCH 5/7]: Implement get_pts_ns() and put_pts_ns()
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 5/7]: Implement get_pts_ns() and put_pts_ns() Implement get_pts_ns() and put_pts_ns() interfaces. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- include/linux/devpts_fs.h | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) Index: 2.6.25-rc8-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc8-mm1.orig/include/linux/devpts_fs.h 2008-04-08 09:18:23.000000000 -0700 +++ 2.6.25-rc8-mm1/include/linux/devpts_fs.h 2008-04-08 13:36:31.000000000 -0700 @@ -27,13 +27,26 @@ struct pts_namespace { extern struct pts_namespace init_pts_ns; #ifdef CONFIG_UNIX98_PTYS - int devpts_new_index(void); void devpts_kill_index(int idx); int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ struct tty_struct *devpts_get_tty(int number); /* get tty structure */ void devpts_pty_kill(int number); /* unlink */ +static inline void free_pts_ns(struct kref *ns_kref) { } + +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) +{ + if (ns && (ns != &init_pts_ns)) + kref_get(&ns->kref); + return ns; +} +static inline void put_pts_ns(struct pts_namespace *ns) +{ + if (ns && (ns != &init_pts_ns)) + kref_put(&ns->kref, free_pts_ns); +} + #else /* Dummy stubs in the no-pty case */ @@ -43,6 +56,12 @@ static inline int devpts_pty_new(struct static inline struct tty_struct *devpts_get_tty(int number) { return NULL; } static inline void devpts_pty_kill(int number) { } +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) +{ + return &init_pts_ns; +} + +static inline void put_pts_ns(struct pts_namespace *ns) { } #endif _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-08T22:00:00-00:00

[RFC][PATCH 6/7]: Determine pts_ns from a pty's inode
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 6/7]: Determine pts_ns from a pty's inode. The devpts interfaces currently operate on a specific pts namespace which they get from the 'current' task. With implementation of containers and cloning of PTS namespaces, we want to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For instance we could bind-mount and pivot-root the child container on '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using $ echo foo > /vserver/vserver1/dev/pts/0 The task doing the above 'echo' could be in parent-pts-ns. So we find the 'pts-ns' of the above file from the inode representing the device rather than from the 'current' task. Note that we need to find and hold a reference to the pts_ns to prevent the pts_ns from being freed while it is being accessed from 'outside'. This patch implements, 'pts_ns_from_inode()' which returns the pts_ns using 'inode->i_sb->s_fs_info'. Since, the 'inode' information is not visible inside devpts code itself, this patch modifies the tty driver code to determine the pts_ns and passes it into devpts. Changelog [v2]: [Serge Hallyn] Use rcu to access sb->s_fs_info. [Serge Hallyn] Simplify handling of ptmx and tty devices by expecting user to create them in /dev/pts (see also devpts-mknod patch) Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- drivers/char/pty.c | 13 +++++- drivers/char/tty_io.c | 96 +++++++++++++++++++++++++++++++++++++++------- fs/devpts/inode.c | 19 +++------ include/linux/devpts_fs.h | 38 +++++++++++++++--- 4 files changed, 134 insertions(+), 32 deletions(-) Index: 2.6.25-rc8-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc8-mm1.orig/include/linux/devpts_fs.h 2008-04-08 13:36:31.000000000 -0700 +++ 2.6.25-rc8-mm1/include/linux/devpts_fs.h 2008-04-08 13:38:08.000000000 -0700 @@ -17,6 +17,7 @@ #include <linux/nsproxy.h> #include <linux/kref.h> #include <linux/idr.h> +#inc…
creator: Sukadev Bhattiprolu
date: 2008-04-08T22:00:26-00:00

[RFC][PATCH 7/7]: Enable cloning PTY namespaces
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 7/7]: Enable cloning PTY namespaces Enable cloning PTY namespaces. Note: We are out of clone_flags! This patch depends on Cedric Le Goater's clone64() patchset. Changelog[v2]: [Serge Hallyn]: Use rcu to access sb->s_fs_info. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> --- fs/devpts/inode.c | 84 ++++++++++++++++++++++++++++++++++++++++++++-- include/linux/devpts_fs.h | 22 ++++++++++-- include/linux/init_task.h | 1 include/linux/nsproxy.h | 2 + include/linux/sched.h | 1 kernel/fork.c | 2 - kernel/nsproxy.c | 17 ++++++++- 7 files changed, 122 insertions(+), 7 deletions(-) Index: 2.6.25-rc8-mm1/include/linux/sched.h =================================================================== --- 2.6.25-rc8-mm1.orig/include/linux/sched.h 2008-04-08 13:38:08.000000000 -0700 +++ 2.6.25-rc8-mm1/include/linux/sched.h 2008-04-08 14:27:41.000000000 -0700 @@ -28,6 +28,7 @@ #define CLONE_NEWPID 0x20000000 /* New pid namespace */ #define CLONE_NEWNET 0x40000000 /* New network namespace */ #define CLONE_IO 0x80000000 /* Clone io context */ +#define CLONE_NEWPTS 0x0000000200000000ULL /* Clone pts ns */ /* * Scheduling policies Index: 2.6.25-rc8-mm1/include/linux/nsproxy.h =================================================================== --- 2.6.25-rc8-mm1.orig/include/linux/nsproxy.h 2008-04-08 13:38:08.000000000 -0700 +++ 2.6.25-rc8-mm1/include/linux/nsproxy.h 2008-04-08 14:27:41.000000000 -0700 @@ -8,6 +8,7 @@ struct mnt_namespace; struct uts_namespace; struct ipc_namespace; struct pid_namespace; +struct pts_namespace; /* * A structure to contain pointers to all per-process @@ -29,6 +30,7 @@ struct nsproxy { struct pid_namespace *pid_ns; struct user_namespace *user_ns; struct net *net_ns; + struct pts_namespace *pts_ns; }; extern struct nsproxy init_nsproxy; Index: 2.6.25-rc8-mm1/include/linux/init_task.h =======…
creator: Sukadev Bhattiprolu
date: 2008-04-08T22:00:54-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: sukadev@us.ibm.com wrote: > Devpts namespace patchset > > In continuation of the implementation of containers in mainline, we need to > support multiple PTY namespaces so that the PTY index (ie the tty names) in > one container is independent of the PTY indices of other containers. For > instance this would allow each container to have a '/dev/pts/0' PTY and > refer to different terminals. > Why do we "need" this? There isn't a fundamental need for this to be a dense numberspace (in fact, there are substantial reasons why it's a bad idea; the only reason the namespace is dense at the moment is because of the hideously bad handing of utmp in glibc.) Other than indicies, this seems to be a more special case of device isolation across namespaces, would that be a more useful problem to solve across the board? hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-09T00:53:31-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: H. Peter Anvin [hpa@zytor.com] wrote: > sukadev@us.ibm.com wrote: >> Devpts namespace patchset >> In continuation of the implementation of containers in mainline, we need >> to >> support multiple PTY namespaces so that the PTY index (ie the tty names) >> in >> one container is independent of the PTY indices of other containers. For >> instance this would allow each container to have a '/dev/pts/0' PTY and >> refer to different terminals. > > Why do we "need" this? There isn't a fundamental need for this to be a > dense numberspace (in fact, there are substantial reasons why it's a bad > idea; the only reason the namespace is dense at the moment is because of > the hideously bad handing of utmp in glibc.) Other than indicies, this > seems to be a more special case of device isolation across namespaces, > would that be a more useful problem to solve across the board? We want to provide isolation between containers, meaning PTYs in container C1 should not be accessible to processes in C2 (unless C2 is an ancestor). The other reason for this in the longer term is for checkpoint/restart. When restarting an application we want to make sure that the PTY indices it was using is available and isolated. We started out with isolating just the indices but added the special-case handling for granting the host visibility into a child-container. A complete device-namespace could solve this, but IIUC, is being planned in the longer term. We are hoping this would provide the isolation in the near-term without being too intrusive or impeding the implementation of the device namespace. Sukadev _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-09T16:23:53-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: sukadev@us.ibm.com wrote: > We want to provide isolation between containers, meaning PTYs in container > C1 should not be accessible to processes in C2 (unless C2 is an ancestor). Yes, I certainly can understand the desire for isolation. That wasn't what my question was about. > The other reason for this in the longer term is for checkpoint/restart. > When restarting an application we want to make sure that the PTY indices > it was using is available and isolated. OK, this would be the motivation for index isolation. > A complete device-namespace could solve this, but IIUC, is being planned > in the longer term. We are hoping this would provide the isolation in the > near-term without being too intrusive or impeding the implementation of > the device namespace. I'm just worried about the accumulation of what feels like ad hoc namespaces, causing a very large combination matrix, a lot of which don't make sense. -hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-09T18:01:16-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting H. Peter Anvin (hpa@zytor.com): > sukadev@us.ibm.com wrote: >> We want to provide isolation between containers, meaning PTYs in container >> C1 should not be accessible to processes in C2 (unless C2 is an ancestor). > > Yes, I certainly can understand the desire for isolation. That wasn't what > my question was about. > >> The other reason for this in the longer term is for checkpoint/restart. >> When restarting an application we want to make sure that the PTY indices >> it was using is available and isolated. > > OK, this would be the motivation for index isolation. > >> A complete device-namespace could solve this, but IIUC, is being planned >> in the longer term. We are hoping this would provide the isolation in the >> near-term without being too intrusive or impeding the implementation of >> the device namespace. > > I'm just worried about the accumulation of what feels like ad hoc > namespaces, causing a very large combination matrix, a lot of which don't > make sense. Hmm, if we were to just call this CLONE_NEWDEV, would that (a) make sense and (b) suitably address your (certainly valid) concern? Basically for now CLONE_NEWDEV wouldn't yet be fully implemented, only unsharing unix98 ptys... -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serge
date: 2008-04-09T19:16:34-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: On Tue, 2008-04-08 at 17:53 -0700, H. Peter Anvin wrote: > sukadev@us.ibm.com wrote: > > Devpts namespace patchset > > > > In continuation of the implementation of containers in mainline, we need to > > support multiple PTY namespaces so that the PTY index (ie the tty names) in > > one container is independent of the PTY indices of other containers. For > > instance this would allow each container to have a '/dev/pts/0' PTY and > > refer to different terminals. > > > > Why do we "need" this? There isn't a fundamental need for this to be a > dense numberspace (in fact, there are substantial reasons why it's a bad > idea; the only reason the namespace is dense at the moment is because of > the hideously bad handing of utmp in glibc.) Other than indicies, this > seems to be a more special case of device isolation across namespaces, > would that be a more useful problem to solve across the board? In short application migration. When you move a running applicaiton from one machine to another you want to be able to keep the same pseudo devices. The isolation that you have noticed is also an important application and like the rest of the namespaces if we can solve the duplicate identifier problem needed to restore checkpoints we also largely solve the isolation problem. This problem is much larger then ptys. ptys are the really in your face aspect of it. There are a more pseudo devices in the kernel and it is the device number to device mapping that we are abstracting. So this really should be done as a device namespace not a pty namespace. I would be happy if the first version of the device namespace could not map anything but pty's (assuming an incremental implementation path). I really don't think we should do a special case for each kind of device. Oh and just skimming the patch summary I'm pretty certain this implementation breaks /sys/class/tty/ptyXX/uevent. Which is another reason why it would be good to have a single device namespace. So we only to capture one more…
creator: ebiederm
date: 2008-04-09T22:15:13-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: serge@hallyn.com wrote: >> I'm just worried about the accumulation of what feels like ad hoc >> namespaces, causing a very large combination matrix, a lot of which don't >> make sense. > > Hmm, if we were to just call this CLONE_NEWDEV, would that (a) make > sense and (b) suitably address your (certainly valid) concern? > > Basically for now CLONE_NEWDEV wouldn't yet be fully implemented, only > unsharing unix98 ptys... That would make sense to me. Also see Eric's note about uevent, however; and there are probably other issues like it. -hpa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: hpa
date: 2008-04-09T22:38:08-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > On Tue, 2008-04-08 at 17:53 -0700, H. Peter Anvin wrote: > > sukadev@us.ibm.com wrote: > > > Devpts namespace patchset > > > > > > In continuation of the implementation of containers in mainline, we need to > > > support multiple PTY namespaces so that the PTY index (ie the tty names) in > > > one container is independent of the PTY indices of other containers. For > > > instance this would allow each container to have a '/dev/pts/0' PTY and > > > refer to different terminals. > > > > > > > Why do we "need" this? There isn't a fundamental need for this to be a > > dense numberspace (in fact, there are substantial reasons why it's a bad > > idea; the only reason the namespace is dense at the moment is because of > > the hideously bad handing of utmp in glibc.) Other than indicies, this > > seems to be a more special case of device isolation across namespaces, > > would that be a more useful problem to solve across the board? > > In short application migration. When you move a running applicaiton > from one machine to another you want to be able to keep the same pseudo > devices. > > The isolation that you have noticed is also an important application and > like the rest of the namespaces if we can solve the duplicate identifier > problem needed to restore checkpoints we also largely solve the > isolation problem. > > This problem is much larger then ptys. ptys are the really in your face > aspect of it. There are a more pseudo devices in the kernel and it is > the device number to device mapping that we are abstracting. So this > really should be done as a device namespace not a pty namespace. > > I would be happy if the first version of the device namespace could not > map anything but pty's (assuming an incremental implementation path). I > really don't think we should do a special case for each kind of device. Sounds like we're all agreed on this and just doing s/CLONE_NEWPTS/CLONE_NEWDEV/ on the current patchse…
creator: serue
date: 2008-04-10T01:59:55-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: On Wed, 2008-04-09 at 20:59 -0500, Serge E. Hallyn wrote: > Feh, so of course sysfs would have the most interactions for a device > namespace, but now we have pty, network, and user namespace all needing > some sort of sysfs solution. For a quickfix for > CONFIG_USER_SCHED+CONFIG_USER_NS, I just moved /sys/kernel/uids/<uid> > to /sys/kernel/uids/<userns_address>/<uid>. But what would be a *good* > general solution? > > ln -s /sys /proc/self/sys? LOL In /proc I prefer the /proc/self approach because we can do it and it is just much easier to setup and use. (Plus we have weird problems if we try and capture more then the pid namespace). For other filesystems the only really viable option is to capture namespaces at mount time, as we are doing for devpts and proc with respect to the pid namespace. For the network namespace where it is very much more then a single directory with symlinks from physical devices pointing at logical network interfaces. My last effort in that area was ok'd by Tejun lightly tested by a few others and misplaced by gregkh so I don't think we have a real problem with resurrecting those patches cleaning them up a bit and merging them. The biggest gotcha with sysfs is that the VFS locking for the dcache is in the wrong order for distributed filesystems, where we would like to make the change atomically on the server and them make the change in the local cache. Or in this case the sysfs internal data structures. The truly nasty case is supporting rename (as sysfs does) as the VFS is not at all happy if you just punt and shoot down the dentries and instantiate new ones. I'm hoping to be able to get back at this in the week or so as things settle down from my move. My last patches should be in my proof of concept network namespace tree, if they don't show up elsewhere. It isn't my perception that we have a design problem rather, we just need to move an important piece of code in a subtle and moderately uninteresting direction for it's primary maintai…
creator: ebiederm
date: 2008-04-10T07:36:20-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > On Wed, 2008-04-09 at 20:59 -0500, Serge E. Hallyn wrote: > > > Feh, so of course sysfs would have the most interactions for a device > > namespace, but now we have pty, network, and user namespace all needing > > some sort of sysfs solution. For a quickfix for > > CONFIG_USER_SCHED+CONFIG_USER_NS, I just moved /sys/kernel/uids/<uid> > > to /sys/kernel/uids/<userns_address>/<uid>. But what would be a *good* > > general solution? > > > > ln -s /sys /proc/self/sys? > > LOL > > In /proc I prefer the /proc/self approach because we can do it and it is > just much easier to setup and use. (Plus we have weird problems if we > try and capture more then the pid namespace). > > For other filesystems the only really viable option is to capture > namespaces at mount time, as we are doing for devpts and proc with > respect to the pid namespace. > > For the network namespace where it is very much more then a single > directory with symlinks from physical devices pointing at logical > network interfaces. > > My last effort in that area was ok'd by Tejun lightly tested by a few > others and misplaced by gregkh so I don't think we have a real problem > with resurrecting those patches cleaning them up a bit and merging them. > > The biggest gotcha with sysfs is that the VFS locking for the dcache > is in the wrong order for distributed filesystems, where we would like > to make the change atomically on the server and them make the change in > the local cache. Or in this case the sysfs internal data structures. > The truly nasty case is supporting rename (as sysfs does) as the VFS > is not at all happy if you just punt and shoot down the dentries and > instantiate new ones. > > I'm hoping to be able to get back at this in the week or so as things > settle down from my move. My last patches should be in my proof of > concept network namespace tree, if they don't show up elsewhere. > > It isn't my perception that we have a design prob…
creator: serue
date: 2008-04-10T16:44:36-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | > | > Further what I did for the network namespace should easily handle the | > uid/gid namespace and should be a good starting place for a general | > device namespace. | | Agreed. What's the git url and which branch do i use for your proof | of concept tree? I'll do the userns patch on top of that. I assume | Suka will do the same for ptys? | Sure. BTW, can we push the following 3 helper patches in the set. I believe they will be required to support multiple pts namespaces, even if the actual way we do it is not final yet. [PATCH 1/7]: Propagate error code from devpts_pty_new [PATCH 2/7]: Factor out PTY index allocation [PATCH 3/7]: Enable multiple mounts of /dev/pts Sukadev _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-04-10T20:58:00-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > On Wed, 2008-04-09 at 20:59 -0500, Serge E. Hallyn wrote: > > > Feh, so of course sysfs would have the most interactions for a device > > namespace, but now we have pty, network, and user namespace all needing > > some sort of sysfs solution. For a quickfix for > > CONFIG_USER_SCHED+CONFIG_USER_NS, I just moved /sys/kernel/uids/<uid> > > to /sys/kernel/uids/<userns_address>/<uid>. But what would be a *good* > > general solution? > > > > ln -s /sys /proc/self/sys? > > LOL > > In /proc I prefer the /proc/self approach because we can do it and it is > just much easier to setup and use. (Plus we have weird problems if we > try and capture more then the pid namespace). > > For other filesystems the only really viable option is to capture > namespaces at mount time, as we are doing for devpts and proc with > respect to the pid namespace. > > For the network namespace where it is very much more then a single > directory with symlinks from physical devices pointing at logical > network interfaces. > > My last effort in that area was ok'd by Tejun lightly tested by a few > others and misplaced by gregkh so I don't think we have a real problem > with resurrecting those patches cleaning them up a bit and merging them. > > The biggest gotcha with sysfs is that the VFS locking for the dcache > is in the wrong order for distributed filesystems, where we would like > to make the change atomically on the server and them make the change in > the local cache. Or in this case the sysfs internal data structures. > The truly nasty case is supporting rename (as sysfs does) as the VFS > is not at all happy if you just punt and shoot down the dentries and > instantiate new ones. > > I'm hoping to be able to get back at this in the week or so as things > settle down from my move. My last patches should be in my proof of > concept network namespace tree, if they don't show up elsewhere. Is that the tree I'd get from git-fetch git://git.ker…
creator: serue
date: 2008-04-22T14:25:39-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: >> >> I'm hoping to be able to get back at this in the week or so as things >> settle down from my move. My last patches should be in my proof of >> concept network namespace tree, if they don't show up elsewhere. > > Is that the tree I'd get from > > git-fetch > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-netns.git > master:ebieder.master Yes. > ? So I'd add a user_ns to the struct sysfs_tag_info? > > If so I'll give it a whirl. Sounds good. My apologies I keep being almost on the verge of getting someplace. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2008-04-22T18:53:07-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > >> > >> I'm hoping to be able to get back at this in the week or so as things > >> settle down from my move. My last patches should be in my proof of > >> concept network namespace tree, if they don't show up elsewhere. > > > > Is that the tree I'd get from > > > > git-fetch > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-netns.git > > master:ebieder.master > > Yes. > > > ? So I'd add a user_ns to the struct sysfs_tag_info? > > > > If so I'll give it a whirl. > > Sounds good. My apologies I keep being almost on the verge > of getting someplace. Ok I've got the sysfs relevant patches ported to 2.6.25, and am looking at how to extend it to handle /sys/kernel/uids. You have tagging tied intimately to struct class. So the question is should I generalize the taggint to deal with kobjects instead, or create a struct class user and make /sys/kernel/uids a symlink to /sys/class/user/uids? Opinions? thanks, -serge PS: If you want me to post the patchset before handling userns I can do that, otherwise I was just going to wait until I'm done with userns. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2008-04-23T14:36:10-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Serge E. Hallyn (serue@us.ibm.com): > Quoting Eric W. Biederman (ebiederm@xmission.com): > > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > >> > > >> I'm hoping to be able to get back at this in the week or so as things > > >> settle down from my move. My last patches should be in my proof of > > >> concept network namespace tree, if they don't show up elsewhere. > > > > > > Is that the tree I'd get from > > > > > > git-fetch > > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-netns.git > > > master:ebieder.master > > > > Yes. > > > > > ? So I'd add a user_ns to the struct sysfs_tag_info? > > > > > > If so I'll give it a whirl. > > > > Sounds good. My apologies I keep being almost on the verge > > of getting someplace. > > Ok I've got the sysfs relevant patches ported to 2.6.25, and am looking > at how to extend it to handle /sys/kernel/uids. You have tagging tied > intimately to struct class. So the question is should I generalize the > taggint to deal with kobjects instead, or create a struct class user > and make /sys/kernel/uids a symlink to /sys/class/user/uids? Heh, never mind, I was thinking class was a kobject class, not a device class :) So I'll just have to generalize tagging. thanks, -serge > Opinions? > > thanks, > -serge > > PS: If you want me to post the patchset before handling userns I can do > that, otherwise I was just going to wait until I'm done with userns. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2008-04-23T17:57:49-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > Quoting Serge E. Hallyn (serue@us.ibm.com): >> Quoting Eric W. Biederman (ebiederm@xmission.com): >> > "Serge E. Hallyn" <serue@us.ibm.com> writes: >> > >> >> > >> I'm hoping to be able to get back at this in the week or so as things >> > >> settle down from my move. My last patches should be in my proof of >> > >> concept network namespace tree, if they don't show up elsewhere. >> > > >> > > Is that the tree I'd get from >> > > >> > > git-fetch >> > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-netns.git >> > > master:ebieder.master >> > >> > Yes. >> > >> > > ? So I'd add a user_ns to the struct sysfs_tag_info? >> > > >> > > If so I'll give it a whirl. >> > >> > Sounds good. My apologies I keep being almost on the verge >> > of getting someplace. >> >> Ok I've got the sysfs relevant patches ported to 2.6.25, and am looking >> at how to extend it to handle /sys/kernel/uids. You have tagging tied >> intimately to struct class. So the question is should I generalize the >> taggint to deal with kobjects instead, or create a struct class user >> and make /sys/kernel/uids a symlink to /sys/class/user/uids? > > Heh, never mind, I was thinking class was a kobject class, not a device > class :) So I'll just have to generalize tagging. Yes. You just need a way to get the tags there. At the level of sysfs it is fairly general. Getting through the kobject layer is a different story. I suspect since you are working on this and I seem to be stuck in molasses at the moment it makes sense to figure out what it will take to handle the uid namespace before pushing these patches again. Taking a quick look and having a clue what we will need to do for a theoretical device namespace is also a possibility. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2008-04-23T18:49:30-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > > Quoting Serge E. Hallyn (serue@us.ibm.com): > >> Quoting Eric W. Biederman (ebiederm@xmission.com): > >> > "Serge E. Hallyn" <serue@us.ibm.com> writes: > >> > >> > >> > >> I'm hoping to be able to get back at this in the week or so as things > >> > >> settle down from my move. My last patches should be in my proof of > >> > >> concept network namespace tree, if they don't show up elsewhere. > >> > > > >> > > Is that the tree I'd get from > >> > > > >> > > git-fetch > >> > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-netns.git > >> > > master:ebieder.master > >> > > >> > Yes. > >> > > >> > > ? So I'd add a user_ns to the struct sysfs_tag_info? > >> > > > >> > > If so I'll give it a whirl. > >> > > >> > Sounds good. My apologies I keep being almost on the verge > >> > of getting someplace. > >> > >> Ok I've got the sysfs relevant patches ported to 2.6.25, and am looking > >> at how to extend it to handle /sys/kernel/uids. You have tagging tied > >> intimately to struct class. So the question is should I generalize the > >> taggint to deal with kobjects instead, or create a struct class user > >> and make /sys/kernel/uids a symlink to /sys/class/user/uids? > > > > Heh, never mind, I was thinking class was a kobject class, not a device > > class :) So I'll just have to generalize tagging. > > Yes. You just need a way to get the tags there. > > At the level of sysfs it is fairly general. > Getting through the kobject layer is a different story. Heh, well I tried several approaches - adding tag_ops to kset, to ktype, etc. Finally ended up just calling sysfs_enable_tagging on /sys/kernel/uids when that is created. It's now working perfectly. > I suspect since you are working on this and I seem to be stuck > in molasses at the moment it makes sense to figure out what it > will take to handle the uid namespace before pushing these > patches again. I h…
creator: serue
date: 2008-04-25T19:21:02-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > Heh, well I tried several approaches - adding tag_ops to kset, to ktype, > etc. Finally ended up just calling sysfs_enable_tagging on > /sys/kernel/uids when that is created. It's now working perfectly. Sounds good. >> I suspect since you are working on this and I seem to be stuck >> in molasses at the moment it makes sense to figure out what it >> will take to handle the uid namespace before pushing these >> patches again. > > I had ported your patches to 2.6.25, but Benjamin in the meantime ported > them to 2.6.25-mm1. Since that's closer to the -net tree it's a more > useful port, so I'll let him post his patchset. Then I'll send the > userns patch on top of that. While I'm not actually able to send > network traffic over a veth dev (I probably am still not setting it up > right), I am able to pass veth devices into network namespaces, and the > user namespaces are properly handled. > > I believe Benjamin did notice a problem with some symlinks not existing, > and I think we want one more patch on top of yours removing the > hold_net() from sysfs_mount, which I don't think was what you really > wanted to do. By simply removing that, if all tasks in a netns go away, > the netns actually goes away and a lookup under a bind-mounted copy of > its /sys/class/net is empty. I will have to look, I need to refresh myself on where all of this code is. I think hold_net was what I wanted. A record that there is a user but not something that will keep the network namespace from going away. Essentially hold_net should be a debugging check rather then a real limitation. > Anyway the patches should be hitting the list next week. Cool. We can figure out what we need to do to merge them from there. >> Taking a quick look and having a clue what we will need to >> do for a theoretical device namespace is also a possibility. > > I'm not sure I'm familiar enough with the kobject/class/sysfs/device > relationships yet to comment on that. I…
creator: ebiederm
date: 2008-04-25T19:47:27-00:00

Re: [RFC][PATCH 0/7] Clone PTS namespace
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > > > Heh, well I tried several approaches - adding tag_ops to kset, to ktype, > > etc. Finally ended up just calling sysfs_enable_tagging on > > /sys/kernel/uids when that is created. It's now working perfectly. > > Sounds good. > > >> I suspect since you are working on this and I seem to be stuck > >> in molasses at the moment it makes sense to figure out what it > >> will take to handle the uid namespace before pushing these > >> patches again. > > > > I had ported your patches to 2.6.25, but Benjamin in the meantime ported > > them to 2.6.25-mm1. Since that's closer to the -net tree it's a more > > useful port, so I'll let him post his patchset. Then I'll send the > > userns patch on top of that. While I'm not actually able to send > > network traffic over a veth dev (I probably am still not setting it up > > right), I am able to pass veth devices into network namespaces, and the > > user namespaces are properly handled. > > > > I believe Benjamin did notice a problem with some symlinks not existing, > > and I think we want one more patch on top of yours removing the > > hold_net() from sysfs_mount, which I don't think was what you really > > wanted to do. By simply removing that, if all tasks in a netns go away, > > the netns actually goes away and a lookup under a bind-mounted copy of > > its /sys/class/net is empty. > > I will have to look, I need to refresh myself on where all of this code is. > I think hold_net was what I wanted. A record that there is a user > but not something that will keep the network namespace from going away. > > Essentially hold_net should be a debugging check rather then a > real limitation. Ah, I see, I assumed it actually pinned it. Sorry, never mind then :) -serge > > Anyway the patches should be hitting the list next week. > > Cool. We can figure out what we need to do to merge them from > there. > > >> Taking a quick look and hav…
creator: serue
date: 2008-04-26T13:02:43-00:00