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
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
[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, and I already answered
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
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
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
* 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
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
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
|
| No, look
* 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't use these
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
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's are
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
-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
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
>
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
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
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
-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
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
-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
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
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
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_NEWPIDS
That is the fix you
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 the fix you were
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 posting.
You
-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 Hat,
-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 isn't
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 exactly is broken
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 can think of a
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 really
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 part of the
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
work.
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 say you
-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
-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
* 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
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
* 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
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
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
* 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
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
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
-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
-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
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
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 ➧
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
-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
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 fix will
* 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 patch below
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 Ulrich about
* 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 to NACK
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 proposed.
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 ready
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 in
* 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 [EMAIL
-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
-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
70 matches
Mail list logo
