[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 to Ingo about
> | >> it
> | >
> | > No, look at my old mail which Ingo referenced in that posting.
> |
> | You pointed only one problem that is not a variation of "how do
> | we handle the case when we pass our pid outside the namespace".
> |
> | This problem with signals is now being resolved at IBM by Sukadev
> | and Serge (I put them in Cc), so this is about to be fixed by the
> | time 2.6.24 releases (I hope).
>
> Yes. We (Oleg, Eric included in Cc) have a patchset to address signals
> issues in child pid namespaces. It is being discussed on Containers list:
>
> https://lists.linux-foundation.org/pipermail/containers/2007-October/008240.html
>
> We will post the patchset to LKML soon.
Yes. Getting all of the cross namespace cases working that we can is a
goal. Currently I don't know if we can do better with the futexes that
have pids in the user/kernel ABI. Plain futexes should be fine.
Implementation wise si_pid is a bit of a pain but we should have that
one sorted out shortly. It is a well understood and we just need to get
the code right.
The pids in the sysvipc space should also be fairly simple to handle
just do a classic struct pid conversion. And convert from struct pid
to a pid_t right at the user/kernel interface.
Unless I missed something we already properly handle giving people
usable pids from the tty layer.
Getting pids working properly for unix domain socket credential when
we cross pid namespaces is another case that needs a struct pid
conversion to get things working, but the kernel should be able to
do the right thing at that point.
In summary when pids are stored inside the kernel we have all of the
needed infrastructure with struct pid to handle doing the right
thing processes communicate between pid namespaces.
Right now we just need to go through every place in the kernel make
certain we haven't over looked something we can handle. And there
are a lot of places where the kernel uses pids....
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
- Re: [patch] PID namespace design bug, workaround
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
