Eric W. Biederman wrote: > Oren Laadan <orenl@xxxxxxxxxxxxxxx> writes: > >> Eric W. Biederman wrote: >>> Pavel Emelyanov <xemul@xxxxxxxxxxxxx> writes: >>> >>>>>> Yet another set of per-namespace IDs along with CLONE_NEWXXX ones? >>>>>> I currently have a way to create all namespaces we have with one >>>>>> syscall. Why don't we have an ability to enter them all with one syscall? >>>>> The CLONE_NEWXXX series of bits has been an royal pain to work with, >>>>> and it appears to be unnecessary complications for no gain. >>>> That's the answer for the "Yet another set..." question. >>>> How about the "Why don't we have..." one? >>> I am not certain which question you are asking: >>> >>> Why don't we have an ability to enter all namespaces with one syscall >>> invocation? >> That's how I understood the question, and I, too, wonder why not ? >> >> By the way, an alternative to using bitmap is to change the prototype >> of setns() to accept an array of FD's: >> >> int setns(int *fds, int nfds); >> >> So the process will atomically enter all the namespaces as specified >> by the FDs. > > We could. Mostly I implemented things in the simplest way possible. > > Semantically I know of no reason why need to enter more than one namespace > at once, and I don't expect entering a namespace to be on anyone's fast > path so every last drop of performance was not crucial. > > The only justification I can think of for more than one namespace at a > time is that because we have a synchronize_rcu() in the kernel we can > loop in the kernel much more quickly than we can loop in userspace. Can't think of a specific scenario, but I wonder if there would be a problem (security or otherwise) with a process that only partly belongs to a container, even if for a short time ? Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
