User: Password:
Subscribe / Log in / New account

Re: [patch] PID namespace design bug, workaround

From:  Linus Torvalds <>
To:  Ingo Molnar <>
Subject:  Re: [patch] PID namespace design bug, workaround
Date:  Sat, 3 Nov 2007 15:40:48 -0700 (PDT)
Message-ID:  <>
Cc:  Dave Hansen <>, Andrew Morton <>, Pavel Emelyanov <>, Ulrich Drepper <>,, "Dinakar Guniguntala [imap]" <>, Sripathi Kodi <>
Archive-link:  Article

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.


(Log in to post comments)

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds