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 ➧
34 matches
Mail list logo
