Re: [patch] PID namespace design bug, workaround

[Pavel Emelyanov <xemul@openvz.org>]

Ingo Molnar wrote:
> * Pavel Emelyanov <xemul@openvz.org> wrote:
> 
>> The "fix" I mention is just returning -EINVAL in case user orders 
>> CLONE_NEWPIDS and compiling out all the namespace cloning code. This 
>> is just a more elegant way to get rid of pid namespaces rather than 
>> Ingo proposed.
> 
> unfortunately i have to NACK that approach. We never allowed broken 
> user-space visible APIs into the kernel like that because it just gives 
> a vector for that breakage to become de-facto used and forced upon the 
> core kernel. Even if they can be .config turned off. That's just a lame 
> excuse that delays the fixing of it. We may mark features that have a 
> good expectation to be fixed as CONFIG_EXPERIMENTAL, and we may mark 

Pid namespaces have more than a good expectations to be fixed, so
feel free to mark the (currently pending) PID_NS config option with
"depends on EXPERIMENTAL".

All the problems I know are slowly getting fixed, but most of them are
just related to "bad pid value is reported to the user space when we 
work inside some new namespace".

Unfortunately, as I can see, all the discussions of pid namespaces 
happen behind my bask, so all I can is just fix the problems I'm 
aware of.

> drivers that nobody maintains anymore as CONFIG_BROKEN, but we dont 
> introduce new core syscall features with CONFIG_BROKEN! We never did and 
> i hope we never will.
> 
> The _only_ way to force the fixing of such type of breakages is to not 
> offer them _at all_. Really, you are proposing a major new extension to 
> lots of important core Linux APIs so please try to solve this problem 
> cleanly, it's really severe. Right now as things stand this containers 

I'm sure, that no *new* problems appear in case you don't enter the new
namespace, so just disable the pid space creation code (with EXPERIMENTAL 
option) and live with the original kernel.

If you point me one, I'd be glad to fix it.

> sub-feature is "a little bit pregnant". This is one of the few cases 
> where we really _must_ say no.
> 
> 	Ingo
>