[RFC][PATCH 0/8][v2]: Enable multiple mounts of devpts
Cedric Le Goater
clg at fr.ibm.com
Fri Aug 29 02:02:52 PDT 2008
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.
>> 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.
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 ?
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.
More information about the Containers