Cedric Le Goater <clg@xxxxxxxxxx> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers