Quoting Cedric Le Goater ([EMAIL PROTECTED]): > Cedric Le Goater wrote: > > Eric W. Biederman wrote: > >> Cedric Le Goater <[EMAIL PROTECTED]> 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 clone(CLONE_NEWMNT); 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. -serge _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel