> convenient and global way of identifying contexts.)
>
> i asked Ulrich about this and it turns out he has warned about this
> early on:
>
>
http://www.nabble.com/Re%3A-question%3A-pid-space-semantics.-p3409990.html
>
> but this problem is still present in the code, and it has been recently
> committed into mainline via:
>
> commit 30e49c263e36341b60b735cbef5ca37912549264
> Author: Pavel Emelyanov <xemul@openvz.org>
> Date: Thu Oct 18 23:40:10 2007 -0700
>
> pid namespaces: allow cloning of new namespace
>
> without these problems having been resolved. A full-scale revert is
> probably too intrusive, but at minimum we need to turn off user-space
> access to this feature via this simple patch. Until this issue is
> resolved properly the new PID namespace code needs to be turned off.
> Letting this into 2.6.24 would be a disaster.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> kernel/fork.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> Index: v/kernel/fork.c
> ===================================================================
> --- v.orig/kernel/fork.c
> +++ v/kernel/fork.c
> @@ -1420,6 +1420,14 @@ long do_fork(unsigned long clone_flags,
> int trace = 0;
> long nr;
>
> + /*
> + * PID namespaces are broken at the moment: they do not allow
> + * certain PID based syscalls (such as futexes) to be used
> + * across namespaces. This is broken and must not be allowed,
> + * so we keep this feature turned off until it's properly fixed.
> + */
> + clone_flags &= ~CLONE_NEWPID;
> +
> if (unlikely(current->ptrace)) {
> trace = fork_traceflag (clone_flags);
> if (trace)
>
