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

[Cedric Le Goater]

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 ?



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

	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.

Thanks !

C.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers