From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oren Laadan Subject: Re: [Devel] [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts Date: Wed, 06 Feb 2008 14:25:09 -0500 Message-ID: <47AA0995.9020003@cs.columbia.edu> References: <20080206050428.GA19461@us.ibm.com> <20080206051055.GC19764@us.ibm.com> <47A9D8D4.6030404@openvz.org> <20080206161608.GA16278@sergelap.austin.ibm.com> <47A9DF31.2040302@openvz.org> <20080206164328.GA16726@sergelap.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080206164328.GA16726-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Serge E. Hallyn" Cc: Containers , Cedric Le Goater , Pavel Emelyanov List-Id: containers.vger.kernel.org Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org): >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org): >>>> sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote: >>>>> From: Sukadev Bhattiprolu >>>>> 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 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. 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. (yes, X per-se needs to provide remote display as opposed to use local hardware; see http://www.ncl.cs.columbia.edu/research/thinc/) [SNIP] Oren.