Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pavel Emelyanov wrote:
>> Having access to the same IPCs in different pid namespaces won't work.
>> Having access to the same filesystem in different IPC namespaces won't work.
>> Having access to the same UID namespace in
[EMAIL PROTECTED] writes:
> Pavel Emelianov [EMAIL PROTECTED] wrote:
> | Ulrich Drepper wrote:
> | > -BEGIN PGP SIGNED MESSAGE-
> | > Hash: SHA1
> | >
> | > Pavel Emelyanov wrote:
> | >>> Isn't it this?
> | >>>
> | >>> http://lkml.org/lkml/2007/11/1/141
> | >> That was the initial problem
On Sat, 3 Nov 2007, Arjan van de Ven wrote:
On Sat, 3 Nov 2007 15:40:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
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
On Sat, 3 Nov 2007 15:40:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> 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
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 du
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 2 Nov 2007, Dave Hansen wrote:
> >
> > There are certainly more of these, but here is one In the futex
> > userspace address, we install the current pid's vnr into a userspace
> > address.
>
> Now, realistically, why not just say "you can'
Pavel Emelianov [EMAIL PROTECTED] wrote:
| Ulrich Drepper wrote:
| > -BEGIN PGP SIGNED MESSAGE-
| > Hash: SHA1
| >
| > Pavel Emelyanov wrote:
| >>> Isn't it this?
| >>>
| >>> http://lkml.org/lkml/2007/11/1/141
| >> That was the initial problem, and I already answered to Ingo about
| >> it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Emelyanov wrote:
> Having access to the same IPCs in different pid namespaces won't work.
> Having access to the same filesystem in different IPC namespaces won't work.
> Having access to the same UID namespace in different VFS namespaces won't
On Fri, 2007-11-02 at 10:39 -0700, Linus Torvalds wrote:
>
> On Fri, 2 Nov 2007, Dave Hansen wrote:
> >
> > There are certainly more of these, but here is one In the futex
> > userspace address, we install the current pid's vnr into a userspace
> > address.
>
> Now, realistically, why not just
On Fri, Nov 02, 2007 at 06:58:47PM +0300, Pavel Emelyanov wrote:
> Having access to the same IPCs in different pid namespaces won't work.
> Having access to the same filesystem in different IPC namespaces won't work.
> Having access to the same UID namespace in different VFS namespaces won't
> wor
On Fri, 2 Nov 2007, Dave Hansen wrote:
>
> There are certainly more of these, but here is one In the futex
> userspace address, we install the current pid's vnr into a userspace
> address.
Now, realistically, why not just say "you can't use these things across
namespaces"? Does anybody reall
On Fri, 2007-11-02 at 01:04 -0700, Andrew Morton wrote:
> > > That is the "fix" you were referring to? I was hoping you have a sketch
> > > for a real solution. If nobody can think of a way to fix this PID
> >
> > Looks like we misunderstood each other. Can you please elaborate on
> > what exac
Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pavel Emelyanov wrote:
>> So is "everything else", you mentioned, covered with the problems
>> above?
>
> No, it's not. If you'd read the mail carefully you'd notice that the
> use of PIDs especially in robust futexes is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Emelyanov wrote:
> So is "everything else", you mentioned, covered with the problems
> above?
No, it's not. If you'd read the mail carefully you'd notice that the
use of PIDs especially in robust futexes is part of the API and that it
simply is
Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pavel Emelyanov wrote:
>>> Isn't it this?
>>>
>>> http://lkml.org/lkml/2007/11/1/141
>> That was the initial problem, and I already answered to Ingo about
>> it
>
> No, look at my old mail which Ingo referenced in that po
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Emelyanov wrote:
>> Isn't it this?
>>
>> http://lkml.org/lkml/2007/11/1/141
>
> That was the initial problem, and I already answered to Ingo about
> it
No, look at my old mail which Ingo referenced in that posting.
- --
➧ Ulrich Drepper ➧ Red
Andrew Morton wrote:
> On Fri, 02 Nov 2007 10:55:02 +0300 Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
>
>> Ulrich Drepper wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Pavel Emelyanov wrote:
The "fix" I mention is just returning -EINVAL in case user orders
CLONE_NE
On Fri, 02 Nov 2007 10:55:02 +0300 Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> Ulrich Drepper wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Pavel Emelyanov wrote:
> >> The "fix" I mention is just returning -EINVAL in case user orders
> >> CLONE_NEWPIDS
> >
> > That is th
Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pavel Emelyanov wrote:
>> The "fix" I mention is just returning -EINVAL in case user orders
>> CLONE_NEWPIDS
>
> That is the "fix" you were referring to? I was hoping you have a sketch
> for a real solution. If nobody
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> but this problem is still present in the code, and it has been recently
> committed into mainline via:
>
> commit 30e49c263e36341b60b735cbef5ca37912549264
> Author: Pavel Emelyanov <[EMAIL PROTECTED]>
> Date: Thu Oct 18
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Emelyanov wrote:
> The "fix" I mention is just returning -EINVAL in case user orders
> CLONE_NEWPIDS
That is the "fix" you were referring to? I was hoping you have a sketch
for a real solution. If nobody can think of a way to fix this PID
nam
* Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 01, 2007 at 04:05:37PM +0100, Ingo Molnar wrote:
> > + if (clone_flags & CLONE_NEWPID)
> > + return -ENOSYS;
>
> I'd use EINVAL instead of ENOSYS...
ok, updated patch below.
Ingo
>
From: Ingo Molnar <[
On Thu, Nov 01, 2007 at 04:05:37PM +0100, Ingo Molnar wrote:
> + if (clone_flags & CLONE_NEWPID)
> + return -ENOSYS;
I'd use EINVAL instead of ENOSYS...
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, 2007-11-01 at 07:56 -0700, Ulrich Drepper wrote:
> Pavel Emelyanov wrote:
> > With this set we'll be able to mark pid namespaces as EXPERIMENTAL
> > or even BROKEN, so nobody will be able to crate them. So can we, please,
> > keep things as they are for now - the appropriate fix will be re
Ingo Molnar wrote:
> * Pavel Emelyanov <[EMAIL PROTECTED]> 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 propose
* Pavel Emelyanov <[EMAIL PROTECTED]> 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 t
Peter Zijlstra wrote:
> On Thu, 2007-11-01 at 17:51 +0300, Pavel Emelyanov wrote:
>
>> So can we, please,
>> keep things as they are for now - the appropriate fix will be ready
>> soon.
>
> Just for the curious, could you outline on how you intend to fix this?
I have already answered to Ulric
Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pavel Emelyanov wrote:
>> With this set we'll be able to mark pid namespaces as EXPERIMENTAL
>> or even BROKEN, so nobody will be able to crate them. So can we, please,
>> keep things as they are for now - the appropriate
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > + clone_flags &= ~CLONE_NEWPID;
>
> I think the call should rather fail than silently drop the bit but
> aside from that I agree. The problems we'd run into if the feature is
> getting used as-is are severe.
does the patc
Ingo Molnar wrote:
> while checking recent commits to the kernel core i took a look at the
> PID namespaces implementation, and it has a fatal flaw: it breaks
> futexes and various libraries (and other stuff) that use PIDs as the
> means of identifying tasks, by not providing any means of global
On Thu, 2007-11-01 at 17:51 +0300, Pavel Emelyanov wrote:
> So can we, please,
> keep things as they are for now - the appropriate fix will be ready
> soon.
Just for the curious, could you outline on how you intend to fix this?
-
To unsubscribe from this list: send the line "unsubscribe linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Emelyanov wrote:
> With this set we'll be able to mark pid namespaces as EXPERIMENTAL
> or even BROKEN, so nobody will be able to crate them. So can we, please,
> keep things as they are for now - the appropriate fix will be ready
> soon.
You
Ingo Molnar wrote:
> while checking recent commits to the kernel core i took a look at the
> PID namespaces implementation, and it has a fatal flaw: it breaks
> futexes and various libraries (and other stuff) that use PIDs as the
> means of identifying tasks, by not providing any means of global
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> + clone_flags &= ~CLONE_NEWPID;
I think the call should rather fail than silently drop the bit but aside
from that I agree. The problems we'd run into if the feature is getting
used as-is are severe.
- --
➧ Ulrich Drepper ➧
while checking recent commits to the kernel core i took a look at the
PID namespaces implementation, and it has a fatal flaw: it breaks
futexes and various libraries (and other stuff) that use PIDs as the
means of identifying tasks, by not providing any means of global
identification that work
35 matches
Mail list logo
