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
