|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Re: [patch] PID namespace design bug, workaround|
|| ||Sat, 3 Nov 2007 15:40:48 -0700 (PDT)|
|| ||Dave Hansen <haveblue-AT-us.ibm.com>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Pavel Emelyanov <xemul-AT-openvz.org>,
Ulrich Drepper <drepper-AT-redhat.com>,
"Dinakar Guniguntala [imap]" <dino-AT-in.ibm.com>,
Sripathi Kodi <sripathik-AT-in.ibm.com>|
On Sat, 3 Nov 2007, Ingo Molnar wrote:
> - one problem is that this condition is 'invisible'. If two namespaces
> happen to access the same robust futex (say a yum update from two
> PID namespaces sharing the same read-mostly filesystem) there's silent
> breakage and data corruption due to PID overlap.
.. and this is in *no* way different from thousands of applications that
write their pid to lock-files, and others decide that it's "stale" because
using "kill(pid, 0)" returns that the pid doesn't exist any more.
The solution? You can't do that kind of locking over NFS, or across pid
namespaces. Nobody blames NFS or pid namespaces for it.
> - so via this we isolate an important category of syscalls from
> cross-namespace use perhaps forever.
So? That's inherent to how those stupid stable mutexes work.
I don't understand how you can call this a "PID namespace design bug",
when it clearly has nothing what-so-ever to do with pid namespaces, and
everything to do with the *futexes* that blithely assume that pid's are
unique and that made it part of the user-visible interface.
OF COURSE any pid namespace design will always break such assumptions, but
that's not because of any PID namespace bugs. It's what the whole *point*
of PID namespaces are. If you use pid's (instead of some opaque cookies),
you will not be able to use such things across pid-separation.
to post comments)