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

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> 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