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

Eric W. Biederman ebiederm at xmission.com
Tue Sep 2 02:22:34 PDT 2008


Cedric Le Goater <clg at fr.ibm.com> writes:
> 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.

Right.

> 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.

This is probably the best option. 

You should be able to just wrap create_new_namespaces(flags=0,...)
to create a new one.

And then actually perform the unshare.

Which means in practice you will bump the ref count on
mq_ns and then drop it and insert a new mq_ns pointer but overall
that shouldn't be too bad.

> (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.

We should be able to refactor the code so we don't have lots of
duplication.

> (3) move mq_ns out of nsproxy.  where shall I put it then ? 
>
>     (3.1) task_struct ? 
That is almost interesting.

>     (3.2) mnt namespace maybe ?
>

> BTW, have you taken a look at what dave resent in July ? 

I took a quick look.

> 	https://lists.linux-foundation.org/pipermail/containers/2008-July/011776.html
>
> This is the mqueue namespace patchset using CLONE_NEWIPC to unshare.
>  
> I wonder if there are arguments against that approach. I might have 
> forgotten some of the issues with unshare as I haven't looked at the 
> code for some time.

I don't know that there are any big issues.  But there is a
certain purity in saying the mq namespaces is it's own weird
global namespace that isn't connected to anything else.  Which
unfortunately happens to be the truth.

Eric



More information about the Containers mailing list