OpenVZ Forum - RDF feed
type: channel
items: [RFC][PATCH 0/4] Devpts namespace
items: [RFC][PATCH 1/4]: Factor out PTY index allocation
items: [RFC][PATCH 2/4]: Use interface to access allocated_ptys
items: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
items: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
items: Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
items: Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts

[RFC][PATCH 0/4] Devpts namespace
type: item
description: Serge, Matt, please sign-off on these patches as you see fit. --- 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/4]: Factor out PTY index allocation [PATCH 2/4]: Use interface to access allocated_ptys [PATCH 3/4]: Enable multiple mounts of /dev/pts [PATCH 4/4]: Enable cloning PTY namespaces Todo: - This patchset depends on availability of additional clone flags !!! - Needs more testing. Changelog: This patchset is based on earlier versions developed by Serge Hallyn and Matt Helsley. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-02-06T05:04:28-00:00

[RFC][PATCH 1/4]: Factor out PTY index allocation
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 1/4]: 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. Changelog: - Version 0: Based on earlier versions from Serge Hallyn and Matt Helsley. Signed-off-by: Sukadev Bhattiprolu <sukadev@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: linux-2.6.24/drivers/char/tty_io.c =================================================================== --- linux-2.6.24.orig/drivers/char/tty_io.c 2008-01-24 14:58:37.000000000 -0800 +++ linux-2.6.24/drivers/char/tty_io.c 2008-02-05 17:17:11.000000000 -0800 @@ -90,7 +90,6 @@ #include <linux/module.h> #include <linux/smp_lock.h> #include <linux/device.h> -#include <linux/idr.h> #include <linux/wait.h> #include <linux/bitops.h> #include <linux/delay.h> @@ -136,9 +135,6 @@ EXPORT_SYMBOL(tty_mutex); #ifdef CONFIG_UNIX98_PTYS extern struct tty_driver *ptm_driver; /* Unix98 pty masters; for /dev/ptmx */ -extern int pty_limit; /* Config limit on Unix98 ptys */ -static DEFINE_IDR(allocated_ptys); -static DECLARE_MUTEX(allocated_ptys_lock); static int ptmx_open(struct inode *, struct file *); #endif @@ -2568,15 +2564,9 @@ static void release_dev(struct file * fi */ release_tty(tty, idx); -#ifdef CONFIG_UNIX98_PTYS /* Make this pty number available for reallocation */ - if (devpts) { - down(&allocated_ptys_lock); - idr_remove(&allocated_ptys, idx); - up(&allocated_ptys_lock); - } -#endif - + if (devpts) + devpts_kill_index(idx); } /** @@ -2732,29 +2722,13 @@ static int ptmx_open(struct inode * inod struct tty_struct *tty; int retval; int index; - int idr_ret; nonseekable_open(inode, filp); /* find a device that i…
creator: Sukadev Bhattiprolu
date: 2008-02-06T05:09:46-00:00

[RFC][PATCH 2/4]: Use interface to access allocated_ptys
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 2/4]: Use interface to access allocated_ptys In preparation for supporting multiple PTY namespaces, use an inline function to access the 'allocated_ptys' idr. Changelog: - Version 0: Based on earlier versions from Serge Hallyn and Matt Helsley. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Acked-by: Serge Hallyn <serue@us.ibm.com> --- fs/devpts/inode.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) Index: linux-2.6.24/fs/devpts/inode.c =================================================================== --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:17:11.000000000 -0800 +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 @@ -28,6 +28,11 @@ extern int pty_limit; /* Config limit o static DEFINE_IDR(allocated_ptys); static DECLARE_MUTEX(allocated_ptys_lock); +static inline struct idr *current_pts_ns_allocated_ptys(void) +{ + return &allocated_ptys; +} + static struct vfsmount *devpts_mnt; static struct dentry *devpts_root; @@ -167,12 +172,12 @@ int devpts_new_index(void) int idr_ret; retry: - if (!idr_pre_get(&allocated_ptys, GFP_KERNEL)) { + if (!idr_pre_get(current_pts_ns_allocated_ptys(), GFP_KERNEL)) { return -ENOMEM; } down(&allocated_ptys_lock); - idr_ret = idr_get_new(&allocated_ptys, NULL, &index); + idr_ret = idr_get_new(current_pts_ns_allocated_ptys(), NULL, &index); if (idr_ret < 0) { up(&allocated_ptys_lock); if (idr_ret == -EAGAIN) @@ -181,7 +186,7 @@ retry: } if (index >= pty_limit) { - idr_remove(&allocated_ptys, index); + idr_remove(current_pts_ns_allocated_ptys(), index); up(&allocated_ptys_lock); return -EIO; } @@ -192,7 +197,7 @@ retry: void devpts_kill_index(int idx) { down(&allocated_ptys_lock); - idr_remove(&allocated_ptys, idx); + idr_remove(current_pts_ns_allocated_ptys(), idx); up(&allocated_ptys_lock); } _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://l…
creator: Sukadev Bhattiprolu
date: 2008-02-06T05:10:27-00:00

[RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' Changelog: - Version 0: Based on earlier versions from Serge Hallyn and Matt Helsley. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 101 insertions(+), 19 deletions(-) Index: linux-2.6.24/fs/devpts/inode.c =================================================================== --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns } static struct vfsmount *devpts_mnt; -static struct dentry *devpts_root; +static inline struct vfsmount *current_pts_ns_mnt(void) +{ + return devpts_mnt; +} static struct { int setuid; @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, inode->i_fop = &simple_dir_operations; inode->i_nlink = 2; - devpts_root = s->s_root = d_alloc_root(inode); + s->s_root = d_alloc_root(inode); if (s->s_root) return 0; @@ -140,10 +143,53 @@ fail: return -ENOMEM; } +/* + * We use test and set super-block operations to help determine whether we + * need a new super-block for this namespace. get_sb() walks the list of + * existing devpts supers, comparing them with the @data ptr. Since we + * passed 'current's namespace as the @data pointer we can compare the + * namespace pointer in the super-block's 's_fs_info'. If the test is + * TRUE then get_sb() returns a new active reference to the super block. + * Otherwise, it helps us build an active reference to a …
creator: Sukadev Bhattiprolu
date: 2008-02-06T05:10:55-00:00

[RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces Enable cloning PTY namespaces. TODO: This version temporarily uses the clone flag '0x80000000' which is unused in mainline atm, but used for CLONE_IO in -mm. While we must extend clone() (urgently) to solve this, it hopefully does not affect review of the rest of this patchset. Changelog: - Version 0: Based on earlier versions from Serge Hallyn and Matt Helsley. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ include/linux/init_task.h | 1 include/linux/nsproxy.h | 2 + include/linux/sched.h | 2 + kernel/fork.c | 2 - kernel/nsproxy.c | 17 ++++++++- 7 files changed, 146 insertions(+), 14 deletions(-) Index: linux-2.6.24/fs/devpts/inode.c =================================================================== --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 @@ -25,18 +25,25 @@ #define DEVPTS_SUPER_MAGIC 0x1cd1 extern int pty_limit; /* Config limit on Unix98 ptys */ -static DEFINE_IDR(allocated_ptys); static DECLARE_MUTEX(allocated_ptys_lock); +static struct file_system_type devpts_fs_type; + +struct pts_namespace init_pts_ns = { + .kref = { + .refcount = ATOMIC_INIT(2), + }, + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), + .mnt = NULL, +}; static inline struct idr *current_pts_ns_allocated_ptys(void) { - return &allocated_ptys; + return &current->nsproxy->pts_ns->allocated_ptys; } -static struct vfsmount *devpts_mnt; static inline struct vfsmount *current_pts_ns_mnt(void) { - return devpts_mnt; + return current->nsproxy->pts_ns->mnt; } static struct { @@ -59,6 +66,42 @@ static match_table_t tokens = { {Opt_err, NULL} }; +struct pts_namespace *new_pts_ns(void) +{ + struct pts_namespace *ns; + + ns = kmalloc(sizeof(*ns), GFP_KE…
creator: Sukadev Bhattiprolu
date: 2008-02-06T05:11:17-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: sukadev@us.ibm.com wrote: > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces > > Enable cloning PTY namespaces. > > TODO: > This version temporarily uses the clone flag '0x80000000' which > is unused in mainline atm, but used for CLONE_IO in -mm. > While we must extend clone() (urgently) to solve this, it hopefully > does not affect review of the rest of this patchset. > > Changelog: > - Version 0: Based on earlier versions from Serge Hallyn and > Matt Helsley. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > --- > fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- > include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ > include/linux/init_task.h | 1 > include/linux/nsproxy.h | 2 + > include/linux/sched.h | 2 + > kernel/fork.c | 2 - > kernel/nsproxy.c | 17 ++++++++- > 7 files changed, 146 insertions(+), 14 deletions(-) > > Index: linux-2.6.24/fs/devpts/inode.c > =================================================================== > --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 > @@ -25,18 +25,25 @@ > #define DEVPTS_SUPER_MAGIC 0x1cd1 > > extern int pty_limit; /* Config limit on Unix98 ptys */ > -static DEFINE_IDR(allocated_ptys); > static DECLARE_MUTEX(allocated_ptys_lock); > +static struct file_system_type devpts_fs_type; > + > +struct pts_namespace init_pts_ns = { > + .kref = { > + .refcount = ATOMIC_INIT(2), > + }, > + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), > + .mnt = NULL, > +}; > > static inline struct idr *current_pts_ns_allocated_ptys(void) > { > - return &allocated_ptys; > + return &current->nsproxy->pts_ns->allocated_ptys; > } > > -static struct vfsmount *devpts_mnt; > static inline struct vfsmount *current_pts_ns_mnt(void) > { > - return devpts_mnt; > + return current->nsproxy->pts_ns->mnt; > } > > static struct { > @@ -59,6 +66,42 @@ static mat…
creator: Pavel Emelianov
date: 2008-02-06T09:04:15-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > sukadev@us.ibm.com wrote: > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > > Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces > > > > Enable cloning PTY namespaces. > > > > TODO: > > This version temporarily uses the clone flag '0x80000000' which > > is unused in mainline atm, but used for CLONE_IO in -mm. > > While we must extend clone() (urgently) to solve this, it hopefully > > does not affect review of the rest of this patchset. > > > > Changelog: > > - Version 0: Based on earlier versions from Serge Hallyn and > > Matt Helsley. > > > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > > --- > > fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- > > include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ > > include/linux/init_task.h | 1 > > include/linux/nsproxy.h | 2 + > > include/linux/sched.h | 2 + > > kernel/fork.c | 2 - > > kernel/nsproxy.c | 17 ++++++++- > > 7 files changed, 146 insertions(+), 14 deletions(-) > > > > Index: linux-2.6.24/fs/devpts/inode.c > > =================================================================== > > --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > > +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 > > @@ -25,18 +25,25 @@ > > #define DEVPTS_SUPER_MAGIC 0x1cd1 > > > > extern int pty_limit; /* Config limit on Unix98 ptys */ > > -static DEFINE_IDR(allocated_ptys); > > static DECLARE_MUTEX(allocated_ptys_lock); > > +static struct file_system_type devpts_fs_type; > > + > > +struct pts_namespace init_pts_ns = { > > + .kref = { > > + .refcount = ATOMIC_INIT(2), > > + }, > > + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), > > + .mnt = NULL, > > +}; > > > > static inline struct idr *current_pts_ns_allocated_ptys(void) > > { > > - return &allocated_ptys; > > + return &current->nsproxy->pts_ns->allocated_ptys; > > } > > > > -static struct vfsmount *devpts_mnt; > > static inline struct vfsmo…
creator: serue
date: 2008-02-06T15:37:50-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' > > Changelog: > - Version 0: Based on earlier versions from Serge Hallyn and > Matt Helsley. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn <serue@us.ibm.com> Though more of this may be Matt's than mine. > --- > fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 101 insertions(+), 19 deletions(-) > > Index: linux-2.6.24/fs/devpts/inode.c > =================================================================== > --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 > +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns > } > > static struct vfsmount *devpts_mnt; > -static struct dentry *devpts_root; > +static inline struct vfsmount *current_pts_ns_mnt(void) > +{ > + return devpts_mnt; > +} > > static struct { > int setuid; > @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, > inode->i_fop = &simple_dir_operations; > inode->i_nlink = 2; > > - devpts_root = s->s_root = d_alloc_root(inode); > + s->s_root = d_alloc_root(inode); > if (s->s_root) > return 0; > > @@ -140,10 +143,53 @@ fail: > return -ENOMEM; > } > > +/* > + * We use test and set super-block operations to help determine whether we > + * need a new super-block for this namespace. get_sb() walks the list of > + * existing devpts supers, comparing them with the @data ptr. Since we > + * passed 'current's namesp…
creator: serue
date: 2008-02-06T15:42:19-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> sukadev@us.ibm.com wrote: >>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>> Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces >>> >>> Enable cloning PTY namespaces. >>> >>> TODO: >>> This version temporarily uses the clone flag '0x80000000' which >>> is unused in mainline atm, but used for CLONE_IO in -mm. >>> While we must extend clone() (urgently) to solve this, it hopefully >>> does not affect review of the rest of this patchset. >>> >>> Changelog: >>> - Version 0: Based on earlier versions from Serge Hallyn and >>> Matt Helsley. >>> >>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>> --- >>> fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- >>> include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ >>> include/linux/init_task.h | 1 >>> include/linux/nsproxy.h | 2 + >>> include/linux/sched.h | 2 + >>> kernel/fork.c | 2 - >>> kernel/nsproxy.c | 17 ++++++++- >>> 7 files changed, 146 insertions(+), 14 deletions(-) >>> >>> Index: linux-2.6.24/fs/devpts/inode.c >>> =================================================================== >>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 >>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 >>> @@ -25,18 +25,25 @@ >>> #define DEVPTS_SUPER_MAGIC 0x1cd1 >>> >>> extern int pty_limit; /* Config limit on Unix98 ptys */ >>> -static DEFINE_IDR(allocated_ptys); >>> static DECLARE_MUTEX(allocated_ptys_lock); >>> +static struct file_system_type devpts_fs_type; >>> + >>> +struct pts_namespace init_pts_ns = { >>> + .kref = { >>> + .refcount = ATOMIC_INIT(2), >>> + }, >>> + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), >>> + .mnt = NULL, >>> +}; >>> >>> static inline struct idr *current_pts_ns_allocated_ptys(void) >>> { >>> - return &allocated_ptys; >>> + return &current->nsproxy->pts_ns->allocated_ptys; >>> } >>> >>> -static struct vfsmount *devpts_mnt; >>> …
creator: Pavel Emelianov
date: 2008-02-06T15:44:58-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: sukadev@us.ibm.com wrote: > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' > > Changelog: > - Version 0: Based on earlier versions from Serge Hallyn and > Matt Helsley. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > --- > fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 101 insertions(+), 19 deletions(-) > > Index: linux-2.6.24/fs/devpts/inode.c > =================================================================== > --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 > +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns > } > > static struct vfsmount *devpts_mnt; > -static struct dentry *devpts_root; > +static inline struct vfsmount *current_pts_ns_mnt(void) > +{ > + return devpts_mnt; > +} > > static struct { > int setuid; > @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, > inode->i_fop = &simple_dir_operations; > inode->i_nlink = 2; > > - devpts_root = s->s_root = d_alloc_root(inode); > + s->s_root = d_alloc_root(inode); > if (s->s_root) > return 0; > > @@ -140,10 +143,53 @@ fail: > return -ENOMEM; > } > > +/* > + * We use test and set super-block operations to help determine whether we > + * need a new super-block for this namespace. get_sb() walks the list of > + * existing devpts supers, comparing them with the @data ptr. Since we > + * passed 'current's namespace as the @data pointer we can compare the > + * namespace pointer in the super-block's 's_fs_info'. If the test i…
creator: Pavel Emelianov
date: 2008-02-06T15:57:08-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces > > Enable cloning PTY namespaces. > > TODO: > This version temporarily uses the clone flag '0x80000000' which > is unused in mainline atm, but used for CLONE_IO in -mm. > While we must extend clone() (urgently) to solve this, it hopefully > does not affect review of the rest of this patchset. > > Changelog: > - Version 0: Based on earlier versions from Serge Hallyn and > Matt Helsley. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Thanks for carrying this forward, Suka, and Matt. Of course it still needs at least Pavel's concern addressed, but Signed-off-by: Serge Hallyn <serue@us.ibm.com> to start the SOB chain. thanks, -serge > --- > fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- > include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ > include/linux/init_task.h | 1 > include/linux/nsproxy.h | 2 + > include/linux/sched.h | 2 + > kernel/fork.c | 2 - > kernel/nsproxy.c | 17 ++++++++- > 7 files changed, 146 insertions(+), 14 deletions(-) > > Index: linux-2.6.24/fs/devpts/inode.c > =================================================================== > --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 > @@ -25,18 +25,25 @@ > #define DEVPTS_SUPER_MAGIC 0x1cd1 > > extern int pty_limit; /* Config limit on Unix98 ptys */ > -static DEFINE_IDR(allocated_ptys); > static DECLARE_MUTEX(allocated_ptys_lock); > +static struct file_system_type devpts_fs_type; > + > +struct pts_namespace init_pts_ns = { > + .kref = { > + .refcount = ATOMIC_INIT(2), > + }, > + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), > + .mnt = NULL, > +}; > > static inline struct idr *current_pts_ns_allocated_ptys(void) > { > - return &allocated_ptys; > + return &current->nsproxy->pts_ns->allocated_ptys; > }…
creator: serue
date: 2008-02-06T16:03:28-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > sukadev@us.ibm.com wrote: > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > > Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' > > > > Changelog: > > - Version 0: Based on earlier versions from Serge Hallyn and > > Matt Helsley. > > > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > > --- > > fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- > > 1 file changed, 101 insertions(+), 19 deletions(-) > > > > Index: linux-2.6.24/fs/devpts/inode.c > > =================================================================== > > --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 > > +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > > @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns > > } > > > > static struct vfsmount *devpts_mnt; > > -static struct dentry *devpts_root; > > +static inline struct vfsmount *current_pts_ns_mnt(void) > > +{ > > + return devpts_mnt; > > +} > > > > static struct { > > int setuid; > > @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, > > inode->i_fop = &simple_dir_operations; > > inode->i_nlink = 2; > > > > - devpts_root = s->s_root = d_alloc_root(inode); > > + s->s_root = d_alloc_root(inode); > > if (s->s_root) > > return 0; > > > > @@ -140,10 +143,53 @@ fail: > > return -ENOMEM; > > } > > > > +/* > > + * We use test and set super-block operations to help determine whether we > > + * need a new super-block for this namespace. get_sb() walks the list of > > + * existing devpts supers, comparing them with the @data ptr. Sinc…
creator: serue
date: 2008-02-06T16:16:08-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> sukadev@us.ibm.com wrote: >>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>> Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' >>> >>> Changelog: >>> - Version 0: Based on earlier versions from Serge Hallyn and >>> Matt Helsley. >>> >>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>> --- >>> fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- >>> 1 file changed, 101 insertions(+), 19 deletions(-) >>> >>> Index: linux-2.6.24/fs/devpts/inode.c >>> =================================================================== >>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 >>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 >>> @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns >>> } >>> >>> static struct vfsmount *devpts_mnt; >>> -static struct dentry *devpts_root; >>> +static inline struct vfsmount *current_pts_ns_mnt(void) >>> +{ >>> + return devpts_mnt; >>> +} >>> >>> static struct { >>> int setuid; >>> @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, >>> inode->i_fop = &simple_dir_operations; >>> inode->i_nlink = 2; >>> >>> - devpts_root = s->s_root = d_alloc_root(inode); >>> + s->s_root = d_alloc_root(inode); >>> if (s->s_root) >>> return 0; >>> >>> @@ -140,10 +143,53 @@ fail: >>> return -ENOMEM; >>> } >>> >>> +/* >>> + * We use test and set super-block operations to help determine whether we >>> + * need a new super-block for this namespace. get_sb() walks the list of >>> + * existing devpts supers, comparing the…
creator: Pavel Emelianov
date: 2008-02-06T16:24:17-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> sukadev@us.ibm.com wrote: > >>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > >>> Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces > >>> > >>> Enable cloning PTY namespaces. > >>> > >>> TODO: > >>> This version temporarily uses the clone flag '0x80000000' which > >>> is unused in mainline atm, but used for CLONE_IO in -mm. > >>> While we must extend clone() (urgently) to solve this, it hopefully > >>> does not affect review of the rest of this patchset. > >>> > >>> Changelog: > >>> - Version 0: Based on earlier versions from Serge Hallyn and > >>> Matt Helsley. > >>> > >>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > >>> --- > >>> fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- > >>> include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ > >>> include/linux/init_task.h | 1 > >>> include/linux/nsproxy.h | 2 + > >>> include/linux/sched.h | 2 + > >>> kernel/fork.c | 2 - > >>> kernel/nsproxy.c | 17 ++++++++- > >>> 7 files changed, 146 insertions(+), 14 deletions(-) > >>> > >>> Index: linux-2.6.24/fs/devpts/inode.c > >>> =================================================================== > >>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > >>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 > >>> @@ -25,18 +25,25 @@ > >>> #define DEVPTS_SUPER_MAGIC 0x1cd1 > >>> > >>> extern int pty_limit; /* Config limit on Unix98 ptys */ > >>> -static DEFINE_IDR(allocated_ptys); > >>> static DECLARE_MUTEX(allocated_ptys_lock); > >>> +static struct file_system_type devpts_fs_type; > >>> + > >>> +struct pts_namespace init_pts_ns = { > >>> + .kref = { > >>> + .refcount = ATOMIC_INIT(2), > >>> + }, > >>> + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), > >>> + .mnt = NULL, > >>> +}; > >>> > >>> static inline struct idr *current_pts_ns_allocated_ptys(void) > >…
creator: serue
date: 2008-02-06T16:25:57-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>> sukadev@us.ibm.com wrote: >>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>> Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces >>>>> >>>>> Enable cloning PTY namespaces. >>>>> >>>>> TODO: >>>>> This version temporarily uses the clone flag '0x80000000' which >>>>> is unused in mainline atm, but used for CLONE_IO in -mm. >>>>> While we must extend clone() (urgently) to solve this, it hopefully >>>>> does not affect review of the rest of this patchset. >>>>> >>>>> Changelog: >>>>> - Version 0: Based on earlier versions from Serge Hallyn and >>>>> Matt Helsley. >>>>> >>>>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>> --- >>>>> fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- >>>>> include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ >>>>> include/linux/init_task.h | 1 >>>>> include/linux/nsproxy.h | 2 + >>>>> include/linux/sched.h | 2 + >>>>> kernel/fork.c | 2 - >>>>> kernel/nsproxy.c | 17 ++++++++- >>>>> 7 files changed, 146 insertions(+), 14 deletions(-) >>>>> >>>>> Index: linux-2.6.24/fs/devpts/inode.c >>>>> =================================================================== >>>>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 >>>>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 >>>>> @@ -25,18 +25,25 @@ >>>>> #define DEVPTS_SUPER_MAGIC 0x1cd1 >>>>> >>>>> extern int pty_limit; /* Config limit on Unix98 ptys */ >>>>> -static DEFINE_IDR(allocated_ptys); >>>>> static DECLARE_MUTEX(allocated_ptys_lock); >>>>> +static struct file_system_type devpts_fs_type; >>>>> + >>>>> +struct pts_namespace init_pts_ns = { >>>>> + .kref = { >>>>> + .refcount = ATOMIC_INIT(2), >>>>> + }, >>>>> + .allocated_ptys = IDR_INIT(init_pts_ns.allocated_ptys), >>>>> + .mnt = NULL, >>>>> +}; >>>>> >>>>> static inline struct idr *current_pts_n…
creator: Pavel Emelianov
date: 2008-02-06T16:35:18-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> sukadev@us.ibm.com wrote: > >>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > >>> Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' > >>> > >>> Changelog: > >>> - Version 0: Based on earlier versions from Serge Hallyn and > >>> Matt Helsley. > >>> > >>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > >>> --- > >>> fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- > >>> 1 file changed, 101 insertions(+), 19 deletions(-) > >>> > >>> Index: linux-2.6.24/fs/devpts/inode.c > >>> =================================================================== > >>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 > >>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > >>> @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns > >>> } > >>> > >>> static struct vfsmount *devpts_mnt; > >>> -static struct dentry *devpts_root; > >>> +static inline struct vfsmount *current_pts_ns_mnt(void) > >>> +{ > >>> + return devpts_mnt; > >>> +} > >>> > >>> static struct { > >>> int setuid; > >>> @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, > >>> inode->i_fop = &simple_dir_operations; > >>> inode->i_nlink = 2; > >>> > >>> - devpts_root = s->s_root = d_alloc_root(inode); > >>> + s->s_root = d_alloc_root(inode); > >>> if (s->s_root) > >>> return 0; > >>> > >>> @@ -140,10 +143,53 @@ fail: > >>> return -ENOMEM; > >>> } > >>> > >>> +/* > >>> + * We use test and set super-block operations to…
creator: serue
date: 2008-02-06T16:43:28-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: [snip] >> Mmm. I wanted to send one small objection to Cedric's patches with mqns, >> but the thread was abandoned by the time I decided to do-it-right-now. >> >> So I can put it here: forcing the CLONE_NEWNS is not very good, since >> this makes impossible to push a bind mount inside a new namespace, which >> may operate in some chroot environment. But this ability is heavily > > Which direction do you want to go? I'm wondering whether mounts > propagation can address it. Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of vfs tree, that left behind them after chroot, unless they are in the same mntns as you, and you bind mount this parts to their tree. No? > Though really, I think you're right - we shouldn't break the kernel > doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't > force the combination. > >> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >> that would be very very good :) See my next comment about this issue. >> >>> Pavel, not long ago you said you were starting to look at tty and pty >>> stuff - did you have any different ideas on devpts virtualization, or >>> are you ok with this minus your comments thus far? >> I have a similar idea of how to implement this, but I didn't thought >> about the details. As far as this issue is concerned, I see no reasons >> why we need a kern_mount-ed devtpsfs instance. If we don't make such, >> we may safely hold the ptsns from the superblock and be happy. The >> same seems applicable to the mqns, no? > > But the current->nsproxy->devpts->mnt is used in several functions in > patch 3. Indeed. I overlooked this. Then we're in a deep ... problem here. Breaking this circle was not that easy with pid namespaces, so I put the strut in proc_flush_task - when the last task from the namespace exits the kern-mount-ed vfsmnt is dropped, but we can't do the same stuff with devpts. I do not remember now what the problem was and it's already quite late in Moscow, so i…
creator: Pavel Emelianov
date: 2008-02-06T16:56:37-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> Serge E. Hallyn wrote: > >>> Quoting Pavel Emelyanov (xemul@openvz.org): > >>>> sukadev@us.ibm.com wrote: > >>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > >>>>> Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces > >>>>> > >>>>> Enable cloning PTY namespaces. > >>>>> > >>>>> TODO: > >>>>> This version temporarily uses the clone flag '0x80000000' which > >>>>> is unused in mainline atm, but used for CLONE_IO in -mm. > >>>>> While we must extend clone() (urgently) to solve this, it hopefully > >>>>> does not affect review of the rest of this patchset. > >>>>> > >>>>> Changelog: > >>>>> - Version 0: Based on earlier versions from Serge Hallyn and > >>>>> Matt Helsley. > >>>>> > >>>>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > >>>>> --- > >>>>> fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- > >>>>> include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ > >>>>> include/linux/init_task.h | 1 > >>>>> include/linux/nsproxy.h | 2 + > >>>>> include/linux/sched.h | 2 + > >>>>> kernel/fork.c | 2 - > >>>>> kernel/nsproxy.c | 17 ++++++++- > >>>>> 7 files changed, 146 insertions(+), 14 deletions(-) > >>>>> > >>>>> Index: linux-2.6.24/fs/devpts/inode.c > >>>>> =================================================================== > >>>>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 > >>>>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 > >>>>> @@ -25,18 +25,25 @@ > >>>>> #define DEVPTS_SUPER_MAGIC 0x1cd1 > >>>>> > >>>>> extern int pty_limit; /* Config limit on Unix98 ptys */ > >>>>> -static DEFINE_IDR(allocated_ptys); > >>>>> static DECLARE_MUTEX(allocated_ptys_lock); > >>>>> +static struct file_system_type devpts_fs_type; > >>>>> + > >>>>> +struct pts_namespace init_pts_ns = { > >>>>> + .kref = { > >>>>> + .refcount = ATOMIC_INIT(2), > >>>>> + }, > >>>>> …
creator: serue
date: 2008-02-06T17:04:02-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>> Serge E. Hallyn wrote: >>>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>>> sukadev@us.ibm.com wrote: >>>>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>>>> Subject: [RFC][PATCH 4/4]: Enable cloning PTY namespaces >>>>>>> >>>>>>> Enable cloning PTY namespaces. >>>>>>> >>>>>>> TODO: >>>>>>> This version temporarily uses the clone flag '0x80000000' which >>>>>>> is unused in mainline atm, but used for CLONE_IO in -mm. >>>>>>> While we must extend clone() (urgently) to solve this, it hopefully >>>>>>> does not affect review of the rest of this patchset. >>>>>>> >>>>>>> Changelog: >>>>>>> - Version 0: Based on earlier versions from Serge Hallyn and >>>>>>> Matt Helsley. >>>>>>> >>>>>>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>>>> --- >>>>>>> fs/devpts/inode.c | 84 +++++++++++++++++++++++++++++++++++++++------- >>>>>>> include/linux/devpts_fs.h | 52 ++++++++++++++++++++++++++++ >>>>>>> include/linux/init_task.h | 1 >>>>>>> include/linux/nsproxy.h | 2 + >>>>>>> include/linux/sched.h | 2 + >>>>>>> kernel/fork.c | 2 - >>>>>>> kernel/nsproxy.c | 17 ++++++++- >>>>>>> 7 files changed, 146 insertions(+), 14 deletions(-) >>>>>>> >>>>>>> Index: linux-2.6.24/fs/devpts/inode.c >>>>>>> =================================================================== >>>>>>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 >>>>>>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 20:27:41.000000000 -0800 >>>>>>> @@ -25,18 +25,25 @@ >>>>>>> #define DEVPTS_SUPER_MAGIC 0x1cd1 >>>>>>> >>>>>>> extern int pty_limit; /* Config limit on Unix98 ptys */ >>>>>>> -static DEFINE_IDR(allocated_ptys); >>>>>>> static DECLARE_MUTEX(allocated_ptys_lock); >>>>>>> +static struct file_system_type devpts_fs_type; >>>>>>> + >>>>>>> +struct pts_namespace init_pts_ns = { >>>>>>> + .kref = { >>>>>>> + .refcount = ATOMIC_INIT…
creator: Pavel Emelianov
date: 2008-02-06T17:06:15-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > [snip] > > >> Mmm. I wanted to send one small objection to Cedric's patches with mqns, > >> but the thread was abandoned by the time I decided to do-it-right-now. > >> > >> So I can put it here: forcing the CLONE_NEWNS is not very good, since > >> this makes impossible to push a bind mount inside a new namespace, which > >> may operate in some chroot environment. But this ability is heavily > > > > Which direction do you want to go? I'm wondering whether mounts > > propagation can address it. > > Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of > vfs tree, that left behind them after chroot, unless they are in the > same mntns as you, and you bind mount this parts to their tree. No? Well no, but I suspect I'm just not understanding what you want to do. But if the chroot is under /jail1, and you've done, say, mkdir -p /share/pts mkdir -p /jail1/share mount --bind /share /share mount --make-shared /share mount --bind /share /jail1/share mount --make-slave /jail1/share before the chroot-ed tasks were cloned with CLONE_NEWNS, then when you do mount --bind /dev/pts /share/pts from the parent mntns (not that I know why you'd want to do *that* :) then the chroot'ed tasks will see the original mntns's /dev/pts under /jail1/share. > > > Though really, I think you're right - we shouldn't break the kernel > > doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't > > force the combination. > > > >> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag > >> that would be very very good :) See my next comment about this issue. > >> > >>> Pavel, not long ago you said you were starting to look at tty and pty > >>> stuff - did you have any different ideas on devpts virtualization, or > >>> are you ok with this minus your comments thus far? > >> I have a similar idea of how to implement this, but I didn't thought > >> about the details. As far as this issue is concerned, I see no reaso…
creator: serue
date: 2008-02-06T17:32:11-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: >>>>>> >>>>>> +struct pts_namespace *new_pts_ns(void) >>>>>> +{ >>>>>> + struct pts_namespace *ns; >>>>>> + >>>>>> + ns = kmalloc(sizeof(*ns), GFP_KERNEL); >>>>>> + if (!ns) >>>>>> + return ERR_PTR(-ENOMEM); >>>>>> + >>>>>> + ns->mnt = kern_mount_data(&devpts_fs_type, ns); >>>>> You create a circular references here - the namespace >>>>> holds the vfsmnt, the vfsmnt holds a superblock, a superblock >>>>> holds the namespace. >>>> Hmm, yeah, good point. That was probably in my original version last >>>> year, so my fault not Suka's. Suka, would it work to have the >>>> sb->s_info point to the namespace but not grab a reference, than have >>> If you don't then you may be in situation, when this devpts >>> is mounted from userspace and in case the namespace is dead >>> superblock will point to garbage... Superblock MUST hold the >>> namespace :) >> But when the ns is freed sb->s_info would be NULL. Surely the helpers >> can be made to handle that safely? > > Hm... How do we find the proper superblock? Have a reference on > it from the namespace? I'm afraid it will be easy to resolve the > locking issues here. > > I propose another scheme - we simply don't have ANY references > from namespace to superblock/vfsmount, but get the current > namespace in devpts_get_sb() and put in devpts_free_sb(). I've choosen another path in mq_ns. I also don't take any refcount on superblock/vfsmount of the new mq_ns bc of the circular ref. I've considered that namespaces only apply to processes : the refcount of a namespace is incremented each time a new task is cloned and the namespace (in my case mq_ns) is released when the last tasks exists. But this becomes an issue with user mounts which survives task death. you end up having a user mount pointing to a bogus mq_ns. unless you require to have CLONE_NEWNS at the sametime. Now, this CLONE_NEWNS enforcement seems to be an issue with bind mount. ... jumping to the other thread :) C. _______________________________________________ Contai…
creator: Cedric Le Goater
date: 2008-02-06T18:00:22-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> sukadev@us.ibm.com wrote: >>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>> Subject: [RFC][PATCH 3/4]: 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_root' and uses current_pts_mnt() to access 'devpts_mnt' >>> >>> Changelog: >>> - Version 0: Based on earlier versions from Serge Hallyn and >>> Matt Helsley. >>> >>> Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>> --- >>> fs/devpts/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++--------- >>> 1 file changed, 101 insertions(+), 19 deletions(-) >>> >>> Index: linux-2.6.24/fs/devpts/inode.c >>> =================================================================== >>> --- linux-2.6.24.orig/fs/devpts/inode.c 2008-02-05 17:30:52.000000000 -0800 >>> +++ linux-2.6.24/fs/devpts/inode.c 2008-02-05 19:16:39.000000000 -0800 >>> @@ -34,7 +34,10 @@ static inline struct idr *current_pts_ns >>> } >>> >>> static struct vfsmount *devpts_mnt; >>> -static struct dentry *devpts_root; >>> +static inline struct vfsmount *current_pts_ns_mnt(void) >>> +{ >>> + return devpts_mnt; >>> +} >>> >>> static struct { >>> int setuid; >>> @@ -130,7 +133,7 @@ devpts_fill_super(struct super_block *s, >>> inode->i_fop = &simple_dir_operations; >>> inode->i_nlink = 2; >>> >>> - devpts_root = s->s_root = d_alloc_root(inode); >>> + s->s_root = d_alloc_root(inode); >>> if (s->s_root) >>> return 0; >>> >>> @@ -140,10 +143,53 @@ fail: >>> return -ENOMEM; >>> } >>> >>> +/* >>> + * We use test and set super-block operations to help determine whether we >>> + * need a new super-block for this namespace. get_sb() walks the list of >>> + * existing devpts supers, comparing the…
creator: Cedric Le Goater
date: 2008-02-06T18:05:42-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>> sukadev@us.ibm.com wrote: >>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>> Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts [SNIP] >>>> That stuff becomes very very similar to that in proc :) >>>> Makes sense to consolidate. Maybe... >>> Yeah, and the mqns that Cedric sent too. I think Cedric said he'd >>> started an a patch implementing a helper. Cedric? >> Mmm. I wanted to send one small objection to Cedric's patches with mqns, >> but the thread was abandoned by the time I decided to do-it-right-now. >> >> So I can put it here: forcing the CLONE_NEWNS is not very good, since >> this makes impossible to push a bind mount inside a new namespace, which >> may operate in some chroot environment. But this ability is heavily > > Which direction do you want to go? I'm wondering whether mounts > propagation can address it. > > Though really, I think you're right - we shouldn't break the kernel > doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't > force the combination. > >> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >> that would be very very good :) See my next comment about this issue. >> >>> Pavel, not long ago you said you were starting to look at tty and pty >>> stuff - did you have any different ideas on devpts virtualization, or >>> are you ok with this minus your comments thus far? >> I have a similar idea of how to implement this, but I didn't thought >> about the details. As far as this issue is concerned, I see no reasons >> why we need a kern_mount-ed devtpsfs instance. If we don't make such, >> we may safely hold the ptsns from the superblock and be happy. The >> same seems applicable to the mqns, no? > > But the current->nsproxy->devpts->mnt is used in several functions in > patch 3. > >> The reason I have the kern_mount-ed instance of proc f…
creator: Oren Laadan
date: 2008-02-06T19:25:09-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting Oren Laadan (orenl@cs.columbia.edu): > > > Serge E. Hallyn wrote: >> Quoting Pavel Emelyanov (xemul@openvz.org): >>> Serge E. Hallyn wrote: >>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>> sukadev@us.ibm.com wrote: >>>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>>> Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts > [SNIP] > >>>>> That stuff becomes very very similar to that in proc :) >>>>> Makes sense to consolidate. Maybe... >>>> Yeah, and the mqns that Cedric sent too. I think Cedric said he'd >>>> started an a patch implementing a helper. Cedric? >>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, >>> but the thread was abandoned by the time I decided to do-it-right-now. >>> >>> So I can put it here: forcing the CLONE_NEWNS is not very good, since >>> this makes impossible to push a bind mount inside a new namespace, which >>> may operate in some chroot environment. But this ability is heavily >> Which direction do you want to go? I'm wondering whether mounts >> propagation can address it. >> Though really, I think you're right - we shouldn't break the kernel >> doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't >> force the combination. >>> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >>> that would be very very good :) See my next comment about this issue. >>> >>>> Pavel, not long ago you said you were starting to look at tty and pty >>>> stuff - did you have any different ideas on devpts virtualization, or >>>> are you ok with this minus your comments thus far? >>> I have a similar idea of how to implement this, but I didn't thought >>> about the details. As far as this issue is concerned, I see no reasons >>> why we need a kern_mount-ed devtpsfs instance. If we don't make such, >>> we may safely hold the ptsns from the superblock and be happy. The >>> same seems applicable to the mqns, no? >> But the current->nsproxy->devpts->mnt is used in several fun…
creator: serue
date: 2008-02-06T19:37:24-00:00

Re: [RFC][PATCH 4/4]: Enable cloning PTY namespaces
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > >>>>>> > >>>>>> +struct pts_namespace *new_pts_ns(void) > >>>>>> +{ > >>>>>> + struct pts_namespace *ns; > >>>>>> + > >>>>>> + ns = kmalloc(sizeof(*ns), GFP_KERNEL); > >>>>>> + if (!ns) > >>>>>> + return ERR_PTR(-ENOMEM); > >>>>>> + > >>>>>> + ns->mnt = kern_mount_data(&devpts_fs_type, ns); > >>>>> You create a circular references here - the namespace > >>>>> holds the vfsmnt, the vfsmnt holds a superblock, a superblock > >>>>> holds the namespace. > >>>> Hmm, yeah, good point. That was probably in my original version last > >>>> year, so my fault not Suka's. Suka, would it work to have the > >>>> sb->s_info point to the namespace but not grab a reference, than have > >>> If you don't then you may be in situation, when this devpts > >>> is mounted from userspace and in case the namespace is dead > >>> superblock will point to garbage... Superblock MUST hold the > >>> namespace :) > >> But when the ns is freed sb->s_info would be NULL. Surely the helpers > >> can be made to handle that safely? > > > > Hm... How do we find the proper superblock? Have a reference on > > it from the namespace? I'm afraid it will be easy to resolve the > > locking issues here. > > > > I propose another scheme - we simply don't have ANY references > > from namespace to superblock/vfsmount, but get the current > > namespace in devpts_get_sb() and put in devpts_free_sb(). > > I've choosen another path in mq_ns. > > I also don't take any refcount on superblock/vfsmount of the new mq_ns > bc of the circular ref. I've considered that namespaces only apply to > processes : the refcount of a namespace is incremented each time a new > task is cloned and the namespace (in my case mq_ns) is released when > the last tasks exists. But this becomes an issue with user mounts which > survives task death. you end up having a user mount pointing to a bogus > mq_ns. > > unless you require to have CLONE_NEWNS at the sametime. > > Now, this CLONE_NEWNS enforcement…
creator: serue
date: 2008-02-06T19:45:02-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn wrote: > Quoting Oren Laadan (orenl@cs.columbia.edu): >> >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>> Serge E. Hallyn wrote: >>>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>>> sukadev@us.ibm.com wrote: >>>>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>>>> Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts >> [SNIP] >> >>>>>> That stuff becomes very very similar to that in proc :) >>>>>> Makes sense to consolidate. Maybe... >>>>> Yeah, and the mqns that Cedric sent too. I think Cedric said he'd >>>>> started an a patch implementing a helper. Cedric? >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, >>>> but the thread was abandoned by the time I decided to do-it-right-now. >>>> >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since >>>> this makes impossible to push a bind mount inside a new namespace, which >>>> may operate in some chroot environment. But this ability is heavily >>> Which direction do you want to go? I'm wondering whether mounts >>> propagation can address it. >>> Though really, I think you're right - we shouldn't break the kernel >>> doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't >>> force the combination. >>>> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >>>> that would be very very good :) See my next comment about this issue. >>>> >>>>> Pavel, not long ago you said you were starting to look at tty and pty >>>>> stuff - did you have any different ideas on devpts virtualization, or >>>>> are you ok with this minus your comments thus far? >>>> I have a similar idea of how to implement this, but I didn't thought >>>> about the details. As far as this issue is concerned, I see no reasons >>>> why we need a kern_mount-ed devtpsfs instance. If we don't make such, >>>> we may safely hold the ptsns from the superblock and be happy. The >>>> same seems applicable to the mqns, no? >>> …
creator: Oren Laadan
date: 2008-02-06T19:45:10-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting Oren Laadan (orenl@cs.columbia.edu): > > > Serge E. Hallyn wrote: >> Quoting Oren Laadan (orenl@cs.columbia.edu): >>> >>> Serge E. Hallyn wrote: >>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>> Serge E. Hallyn wrote: >>>>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>>>> sukadev@us.ibm.com wrote: >>>>>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>>>>> Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts >>> [SNIP] >>> >>>>>>> That stuff becomes very very similar to that in proc :) >>>>>>> Makes sense to consolidate. Maybe... >>>>>> Yeah, and the mqns that Cedric sent too. I think Cedric said he'd >>>>>> started an a patch implementing a helper. Cedric? >>>>> Mmm. I wanted to send one small objection to Cedric's patches with >>>>> mqns, >>>>> but the thread was abandoned by the time I decided to do-it-right-now. >>>>> >>>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since >>>>> this makes impossible to push a bind mount inside a new namespace, >>>>> which >>>>> may operate in some chroot environment. But this ability is heavily >>>> Which direction do you want to go? I'm wondering whether mounts >>>> propagation can address it. >>>> Though really, I think you're right - we shouldn't break the kernel >>>> doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't >>>> force the combination. >>>>> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >>>>> that would be very very good :) See my next comment about this issue. >>>>> >>>>>> Pavel, not long ago you said you were starting to look at tty and pty >>>>>> stuff - did you have any different ideas on devpts virtualization, or >>>>>> are you ok with this minus your comments thus far? >>>>> I have a similar idea of how to implement this, but I didn't thought >>>>> about the details. As far as this issue is concerned, I see no reasons >>>>> why we need a kern_mount-ed devtpsfs instance. If we don't make such, >>>>> we may safely ho…
creator: serue
date: 2008-02-06T19:58:55-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> [snip] >> >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, >>>> but the thread was abandoned by the time I decided to do-it-right-now. >>>> >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since >>>> this makes impossible to push a bind mount inside a new namespace, which >>>> may operate in some chroot environment. But this ability is heavily >>> Which direction do you want to go? I'm wondering whether mounts >>> propagation can address it. >> Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of >> vfs tree, that left behind them after chroot, unless they are in the >> same mntns as you, and you bind mount this parts to their tree. No? > > Well no, but I suspect I'm just not understanding what you want to do. > But if the chroot is under /jail1, and you've done, say, > > mkdir -p /share/pts > mkdir -p /jail1/share > mount --bind /share /share > mount --make-shared /share > mount --bind /share /jail1/share > mount --make-slave /jail1/share > > before the chroot-ed tasks were cloned with CLONE_NEWNS, then when you > do > > mount --bind /dev/pts /share/pts > > from the parent mntns (not that I know why you'd want to do *that* :) > then the chroot'ed tasks will see the original mntns's /dev/pts under > /jail1/share. I haven't yet tried that, but :( this function static inline int check_mnt(struct vfsmount *mnt) { return mnt->mnt_ns == current->nsproxy->mnt_ns; } and this code in do_loopback if (!check_mnt(nd->mnt) || !check_mnt(old_nd.mnt)) goto out; makes me think that trying to bind a mount from another mntns ot _to_ another is prohibited... Do I miss something? >>> Though really, I think you're right - we shouldn't break the kernel >>> doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't >>> force the combination. >>> >>>> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >>>> that would be ve…
creator: Pavel Emelianov
date: 2008-02-07T09:43:36-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: >>> Breaking this circle was not that easy with pid namespaces, so >>> I put the strut in proc_flush_task - when the last task from the >>> namespace exits the kern-mount-ed vfsmnt is dropped, but we can't >>> do the same stuff with devpts. >> But I still don't see what the problem is with my proposal? So long as >> you agree that if there are no tasks remaining in the devptsns, >> then any task which has its devpts mounted should see an empty directory >> (due to sb->s_info being NULL), I think it works. > > Well, if we _do_ can handle the races with ns->devpts_mnt switch > from not NULL to NULL, then I'm fine with this approach. I 'll take a look at it for the mq namespace. we will need to flush the dcache in some way nop ? to make sure the lookup in the directory fails to return anything after the ns has become NULL. I'm not an fs expert so I might be completely wrong there but I'll study in this direction to see if we can drop the CLONE_NEWNS. > I just remember, that with pid namespaces this caused a complicated > locking and performance degradation. This is the problem I couldn't > remember yesterday. That might have been bc you had to invalidate the /proc dentries ? C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2008-02-07T10:17:27-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: >> Off-topic: does any of you know whether Andrew is willing to accept >> new features in the nearest future? The problem is that I have a >> device visibility controller fixed and pending to send, but I can't >> guess a good time for it :) I have the clone64/unshare64 syscalls ready for most common arches : x86, x86_64, x86_64(32), ppc64, ppc64(32), s390x, s390x(31) do you care to review or shall I send directly to andrew ? There's a freezer patchset also that I need to resend ... C. > Well even if Andrew won't take it I'd like to see it, so I'd appreciate > a resend. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2008-02-07T10:25:09-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Cedric Le Goater wrote: >>> Off-topic: does any of you know whether Andrew is willing to accept >>> new features in the nearest future? The problem is that I have a >>> device visibility controller fixed and pending to send, but I can't >>> guess a good time for it :) > > I have the clone64/unshare64 syscalls ready for most common arches : > > x86, x86_64, x86_64(32), ppc64, ppc64(32), s390x, s390x(31) > > do you care to review or shall I send directly to andrew ? I think you can send them t Andrew :) > There's a freezer patchset also that I need to resend ... > > C. > >> Well even if Andrew won't take it I'd like to see it, so I'd appreciate >> a resend. > _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-02-07T10:50:46-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> [snip] > >> > >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, > >>>> but the thread was abandoned by the time I decided to do-it-right-now. > >>>> > >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since > >>>> this makes impossible to push a bind mount inside a new namespace, which > >>>> may operate in some chroot environment. But this ability is heavily > >>> Which direction do you want to go? I'm wondering whether mounts > >>> propagation can address it. > >> Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of > >> vfs tree, that left behind them after chroot, unless they are in the > >> same mntns as you, and you bind mount this parts to their tree. No? > > > > Well no, but I suspect I'm just not understanding what you want to do. > > But if the chroot is under /jail1, and you've done, say, > > > > mkdir -p /share/pts > > mkdir -p /jail1/share > > mount --bind /share /share > > mount --make-shared /share > > mount --bind /share /jail1/share > > mount --make-slave /jail1/share > > > > before the chroot-ed tasks were cloned with CLONE_NEWNS, then when you > > do > > > > mount --bind /dev/pts /share/pts > > > > from the parent mntns (not that I know why you'd want to do *that* :) > > then the chroot'ed tasks will see the original mntns's /dev/pts under > > /jail1/share. > > I haven't yet tried that, but :( this function > > static inline int check_mnt(struct vfsmount *mnt) > { > return mnt->mnt_ns == current->nsproxy->mnt_ns; > } > > and this code in do_loopback > > if (!check_mnt(nd->mnt) || !check_mnt(old_nd.mnt)) > goto out; > > makes me think that trying to bind a mount from another mntns > ot _to_ another is prohibited... Do I miss something? That's used at the top of explicit mounting paths, so if you found a way to access a nameidata in the other mnt_ns and tried to mount…
creator: serue
date: 2008-02-07T14:22:35-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn wrote: > Quoting Oren Laadan (orenl@cs.columbia.edu): >> >> Serge E. Hallyn wrote: >>> Quoting Oren Laadan (orenl@cs.columbia.edu): >>>> Serge E. Hallyn wrote: >>>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>>> Serge E. Hallyn wrote: >>>>>>> Quoting Pavel Emelyanov (xemul@openvz.org): >>>>>>>> sukadev@us.ibm.com wrote: >>>>>>>>> From: Sukadev Bhattiprolu <sukadev@us.ibm.com> >>>>>>>>> Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts >>>> [SNIP] >>>> [SNIP again] >>>>>> Besides, I planned to include legacy ptys virtualization and console >>>>>> virtualizatin in this namespace, but it seems, that it is not present >>>>>> in this particular one. >>>>> I had been thinking the consoles would have their own ns, since there's >>>>> really nothing linking them, but there really is no good reason why >>>>> userspace should ever want them separate. So I'm fine with combining >>>>> them. >>>> If you want to run something like an X server inside each container >>>> (eg each container holds a desktop session of a different user), then >>>> you need a separate virtual-console namespace for each container. >>> Ok, but whether the consoles and devpts are unshared with the same >>> cloneflag or not isn't an issue, right? >> true. (I misread your comment.) >> ( >> modulo that we are additional-clone-flags-challenged ...) > > Right, plus the fact that the number of clone flags involved becomes > almost obscene. Let's see if Pavel and Suka have a preference, since > one of them seems likely to end up coding it :) > >>>> (yes, X per-se needs to provide remote display as opposed to use >>>> local hardware; see http://www.ncl.cs.columbia.edu/research/thinc/) > > Nice, by the way :) > Thanks :) Still off-topic, this is even nicer (also requires ultrafast checkpoint): http://www.ncl.cs.columbia.edu/publications/sosp2007_dejaview >>> -serge > > thanks, > -serge _______________________________________________ Containers mailing list Containers@lists.linux-fo…
creator: Oren Laadan
date: 2008-02-12T00:34:47-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | | > exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag | > that would be very very good :) See my next comment about this issue. | > | > > Pavel, not long ago you said you were starting to look at tty and pty | > > stuff - did you have any different ideas on devpts virtualization, or | > > are you ok with this minus your comments thus far? | > | > I have a similar idea of how to implement this, but I didn't thought | > about the details. As far as this issue is concerned, I see no reasons | > why we need a kern_mount-ed devtpsfs instance. If we don't make such, | > we may safely hold the ptsns from the superblock and be happy. The | > same seems applicable to the mqns, no? | | But the current->nsproxy->devpts->mnt is used in several functions in | patch 3. Hmm, current_pts_ns_mnt() is used in: devpts_pty_new() devpts_get_tty() devpts_pty_kill() All of these return error if current_pts_ns_mnt() returns NULL. So, can we require user-space mount and unmount /dev/pts and return error if any operation is attempted before the mount ? | | > The reason I have the kern_mount-ed instance of proc for pid namespaces | > is that I need a vfsmount to flush task entries from, but allowing | > it to be NULL (i.e. no kern_mount, but optional user mounts) means | > handing all the possible races, which is too heavy. But do we actually | > need the vfsmount for devpts and mqns if no user-space mounts exist? | > | > Besides, I planned to include legacy ptys virtualization and console | > virtualizatin in this namespace, but it seems, that it is not present | > in this particular one. | | I had been thinking the consoles would have their own ns, since there's | really nothing linking them, but there really is no good reason why | userspace should ever want them separate. So I'm fine with combining | them. | | > >>> + sb->s_flags |= MS_ACTIVE; | > >>> + devpts_mnt = mnt; | > >>> + | > >>> + return simple_set_mnt(mnt, sb); | …
creator: Sukadev Bhattiprolu
date: 2008-02-14T18:16:58-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | Serge E. Hallyn wrote: | > Quoting Pavel Emelyanov (xemul@openvz.org): | >> [snip] | >> | >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, | >>>> but the thread was abandoned by the time I decided to do-it-right-now. | >>>> | >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since | >>>> this makes impossible to push a bind mount inside a new namespace, which | >>>> may operate in some chroot environment. But this ability is heavily | >>> Which direction do you want to go? I'm wondering whether mounts | >>> propagation can address it. | >> Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of | >> vfs tree, that left behind them after chroot, unless they are in the | >> same mntns as you, and you bind mount this parts to their tree. No? | > | > Well no, but I suspect I'm just not understanding what you want to do. | > But if the chroot is under /jail1, and you've done, say, | > | > mkdir -p /share/pts | > mkdir -p /jail1/share | > mount --bind /share /share | > mount --make-shared /share | > mount --bind /share /jail1/share | > mount --make-slave /jail1/share | > | > before the chroot-ed tasks were cloned with CLONE_NEWNS, then when you | > do | > | > mount --bind /dev/pts /share/pts | > | > from the parent mntns (not that I know why you'd want to do *that* :) | > then the chroot'ed tasks will see the original mntns's /dev/pts under | > /jail1/share. | | I haven't yet tried that, but :( this function | | static inline int check_mnt(struct vfsmount *mnt) | { | return mnt->mnt_ns == current->nsproxy->mnt_ns; | } | | and this code in do_loopback | | if (!check_mnt(nd->mnt) || !check_mnt(old_nd.mnt)) | goto out; | | makes me think that trying to bind a mount from another mntns | ot _to_ another is prohibited... Do I miss something? | | >>> Though really, I think you're right - we shouldn't break the kernel | >>> doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS…
creator: Sukadev Bhattiprolu
date: 2008-02-14T23:50:27-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: sukadev@us.ibm.com wrote: > Pavel Emelianov [xemul@openvz.org] wrote: > | Serge E. Hallyn wrote: > | > Quoting Pavel Emelyanov (xemul@openvz.org): > | >> [snip] > | >> > | >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, > | >>>> but the thread was abandoned by the time I decided to do-it-right-now. > | >>>> > | >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since > | >>>> this makes impossible to push a bind mount inside a new namespace, which > | >>>> may operate in some chroot environment. But this ability is heavily > | >>> Which direction do you want to go? I'm wondering whether mounts > | >>> propagation can address it. > | >> Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of > | >> vfs tree, that left behind them after chroot, unless they are in the > | >> same mntns as you, and you bind mount this parts to their tree. No? > | > > | > Well no, but I suspect I'm just not understanding what you want to do. > | > But if the chroot is under /jail1, and you've done, say, > | > > | > mkdir -p /share/pts > | > mkdir -p /jail1/share > | > mount --bind /share /share > | > mount --make-shared /share > | > mount --bind /share /jail1/share > | > mount --make-slave /jail1/share > | > > | > before the chroot-ed tasks were cloned with CLONE_NEWNS, then when you > | > do > | > > | > mount --bind /dev/pts /share/pts > | > > | > from the parent mntns (not that I know why you'd want to do *that* :) > | > then the chroot'ed tasks will see the original mntns's /dev/pts under > | > /jail1/share. > | > | I haven't yet tried that, but :( this function > | > | static inline int check_mnt(struct vfsmount *mnt) > | { > | return mnt->mnt_ns == current->nsproxy->mnt_ns; > | } > | > | and this code in do_loopback > | > | if (!check_mnt(nd->mnt) || !check_mnt(old_nd.mnt)) > | goto out; > | > | makes me think that trying to bind a mount from another mntns > | ot _to_ another is prohibited... Do I miss something? > | > | >…
creator: Pavel Emelianov
date: 2008-02-15T07:57:38-00:00

Re: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts
type: item
description: Pavel Emelianov [xemul@openvz.org] wrote: | sukadev@us.ibm.com wrote: | > Pavel Emelianov [xemul@openvz.org] wrote: | > | Serge E. Hallyn wrote: | > | > Quoting Pavel Emelyanov (xemul@openvz.org): | > | >> [snip] | > | >> | > | >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, | > | >>>> but the thread was abandoned by the time I decided to do-it-right-now. | > | >>>> | > | >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since | > | >>>> this makes impossible to push a bind mount inside a new namespace, which | > | >>>> may operate in some chroot environment. But this ability is heavily | > | >>> Which direction do you want to go? I'm wondering whether mounts | > | >>> propagation can address it. | > | >> Hardly. AFAIS there's no way to let the chroot-ed tasks see parts of | > | >> vfs tree, that left behind them after chroot, unless they are in the | > | >> same mntns as you, and you bind mount this parts to their tree. No? | > | > | > | > Well no, but I suspect I'm just not understanding what you want to do. | > | > But if the chroot is under /jail1, and you've done, say, | > | > | > | > mkdir -p /share/pts | > | > mkdir -p /jail1/share | > | > mount --bind /share /share | > | > mount --make-shared /share | > | > mount --bind /share /jail1/share | > | > mount --make-slave /jail1/share | > | > | > | > before the chroot-ed tasks were cloned with CLONE_NEWNS, then when you | > | > do | > | > | > | > mount --bind /dev/pts /share/pts | > | > | > | > from the parent mntns (not that I know why you'd want to do *that* :) | > | > then the chroot'ed tasks will see the original mntns's /dev/pts under | > | > /jail1/share. | > | | > | I haven't yet tried that, but :( this function | > | | > | static inline int check_mnt(struct vfsmount *mnt) | > | { | > | return mnt->mnt_ns == current->nsproxy->mnt_ns; | > | } | > | | > | and this code in do_loopback | > | | > | if (!check_mnt(nd->mnt) || !check_mnt(old_nd.mnt)) | > | goto out;…
creator: Sukadev Bhattiprolu
date: 2008-02-15T17:52:07-00:00