[Devel] Re: [patch -mm 2/4] mqueue namespace : add unshare support

Eric W. Biederman ebiederm at xmission.com
Thu Nov 29 13:49:40 PST 2007


Oren Laadan <orenl at cs.columbia.edu> writes:

> Two comments:
>
> 1) Does it ever make any sense to clone the IPC namespace *without* doing
> so also for the MQ namespace or vice versa ?  Unless there is a good
> reason for doing so, a single CLONE_IPCMQ flag would suffice.

SYSVIPC and POSIX IPC are different, and I don't see any argument for why
they would be in the same namespace.  So for maintenance, testing, and
the fact that we have already shipped a stable version of the IPC
namespace and we would be breaking the ABI if we were to add messages
queues into it now.

Frankly I find it a shame that we had to do more then implement multiple
mounts of the mq filesystem to make this work.

In general when we use the filesystem namespace for new global objects
visible to user space is a design bug.

> 2) Before coming up with a new clone2() or other solution, what about the
> proposed (and debated) sys_indrect() -- if it gets merged it can provide
> the solution.

Bleh.  We have to have the flag parameters and modify all of the code anyway
so I'm not quite certain that sys_indirect make sense.

Certainly in this case if we have namespaces that can not be combined with
CLONE_THREAD we could double assign a field really easily.  Trouble is that
is just a bit icky.

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




More information about the Devel mailing list