[RFC][PATCH 0/8][v2]: Enable multiple mounts of devpts

Serge E. Hallyn serue at us.ibm.com
Mon Sep 1 20:04:26 PDT 2008

Quoting Cedric Le Goater (clg at fr.ibm.com):
> Cedric Le Goater wrote:
> > Eric W. Biederman wrote:
> >> Cedric Le Goater <clg at fr.ibm.com> writes:
> >>
> >>> H. Peter Anvin wrote:
> >>>> Cedric Le Goater wrote:
> >>>>>> I suggest "newinstance", but "newns" works, too.
> >>>>> Could we also use this mount option to 'unshare' a new posix message
> >>>>> queue namespace ?
> >>>> Sorry, I fail to see the connection with devpts here?  Are you
> >>>> suggesting using the same option for another filesystem (if so, which)?
> >>> yes. the posix message queues are also using a single superblock filesystem. 
> >>>
> >>> If we want isolate them (for container needs for example), we also need to 
> >>> create a new sb. The patchset I have uses a clone flag but using a mount 
> >>> 'newns' really sounds like a better idea.
> >> Let's call it newinstance if we are going to use the same option for devpts.
> > 
> > ok.
> > 
> >> We can update "current->nsproxy->mqueuens" when the newinstance flag is passed
> >> and otherwise we can mount whatever is the current mqueue filesystem for
> >> the process.
> > 
> > yes. I'll rebase my previous patchset on this idea.
> Hello Eric,
> I've spent some time on the code and I'm facing some issues with the nsproxy 
> API if we are to keep the mqueue namespace in nsproxy: 
> 	int copy_namespaces(unsigned long flags, struct task_struct *tsk);
> 	void exit_task_namespaces(struct task_struct *tsk);
> 	void switch_task_namespaces(struct task_struct *tsk, struct nsproxy *new);
> 	void free_nsproxy(struct nsproxy *ns);
> 	int unshare_nsproxy_namespaces(unsigned long, struct nsproxy **,
> 		struct fs_struct *);
> nsproxy designed to work closely with the clone flags and it is not well
> suited to be called elsewhere than clone/unshare.
> So I could either : 
> (1) make a special case for the mqueue namespace and duplicate some code 
>     to unshare it from ->get_sb() when the option 'newinstance' is used.
> (2) to avoid duplicating code, use a clone_flags to unshare the mqueue 
>     namespace from ->get_sb() when the option 'newinstance' is used. that 
>     sounds silly because we might as well use sys_unshare() in that case.
> (3) move mq_ns out of nsproxy.  where shall I put it then ? 
>     (3.1) task_struct ? 
>     (3.2) mnt namespace maybe ?

I think the last one is the way to go.

mnt_namespace points to mq_ns.

At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
parent's mq_ns.

If a task does
	mount -o newinstance -t mqueue none /dev/mqueue
then its current->nsproxy->mnt_namespace->mqns is switched
to point to a new instance of the mq_ns.

mnt_ns->mq_ns has pointers to the sb (and hence root dentry) of the
devpts fs.

When a task does mq_open(name, flag), then name is in the mqueuefs
found in current->nsproxy->mnt_namespace->mqns.

But if a task does

	mount --move /dev/mqueue /oldmqueue
	mount -o newinstance -t mqueue none /dev/mqueue

then that task can find files for the old mqueuefs under
/oldmqueue, while mq_open() uses /dev/mqueue since that's
what it finds through its mnt_namespace.


More information about the Containers mailing list