To retain any part of the existing unix process management
we need some processes that show up in multiple pid spaces.
To allow for migration it must be possible for the pids in those pid
spaces to be different.
It is undesirable in the normal case of affairs to allocate more
than one pid per process.
Given the small range of pid values these constraints make an
efficient and general pid space solution challenging.
The question:
If we could add additional pid values in different pid spaces to a
process with a syscall upon demand would that lead to an
implementation everyone could use?
I assume most processes by default only have a pid value in a single
pid space.
The reason I ask is that I believe I know how to implement a cheap
general mechanism for adding additional pids to a process.
Eric
On Tue, 2006-03-14 at 11:43 -0700, Eric W. Biederman wrote:
> The question:
> If we could add additional pid values in different pid spaces to a
> process with a syscall upon demand would that lead to an
> implementation everyone could use?
So, you'd basically only allocate the cross-namespace pids when you
needed to do some kind of cross-namespace management?
pid_t alloc_local_pid(container_handle, pid_t pid_inside_container)
-- Dave
Dave Hansen <[email protected]> writes:
> On Tue, 2006-03-14 at 11:43 -0700, Eric W. Biederman wrote:
>> The question:
>> If we could add additional pid values in different pid spaces to a
>> process with a syscall upon demand would that lead to an
>> implementation everyone could use?
>
> So, you'd basically only allocate the cross-namespace pids when you
> needed to do some kind of cross-namespace management?
Yes, or setup a parent/child relationship. So I think the first
process in a container would always get two pids.
> pid_t alloc_local_pid(container_handle, pid_t pid_inside_container)
That is the idea.
I actually expect the implementation to look very much different.
To me the nice piece of this concept is that it allows all pids
to local to a pid space while still be able to talk to remote
processes.
Eric
Eric W. Biederman wrote:
> To retain any part of the existing unix process management
> we need some processes that show up in multiple pid spaces.
yep.
> To allow for migration it must be possible for the pids in those pid
> spaces to be different.
agree, the process that creates a pidspace is in different pidspaces if you
want to maintain the process hierarchy.
> It is undesirable in the normal case of affairs to allocate more
> than one pid per process.
yes.
> Given the small range of pid values these constraints make an
> efficient and general pid space solution challenging.
>
> The question:
> If we could add additional pid values in different pid spaces to a
> process with a syscall upon demand would that lead to an
> implementation everyone could use?
I don't know yet if we would use it but we need it :) One way of the other.
The creator of a pidspace could be the parent of multiple pidspaces and
hence it needs multiples pids, one in each pidspace.
Could that be done with the syscall creating the pidspace ? because it
seems that the process creating a pidspace is the only candidate ?
> [ ... ]
>
> The reason I ask is that I believe I know how to implement a cheap
> general mechanism for adding additional pids to a process.
OK good. That's what we need to begin with : something cheap to prove the
feature is useful.
We have already implemented the vpid in a very similar way to the openvz
team, although with less optimization and linux feeling. Both efforts and
yours, on pidspaces, didn't prove to be good enough to be valuable.
C.
On Tue, Mar 14, 2006 at 11:43:38AM -0700, Eric W. Biederman wrote:
>
> To retain any part of the existing unix process management
> we need some processes that show up in multiple pid spaces.
hmm ... not sure about that, what 'we' need is a way
to move between pid spaces and to control processes
in a child space from the parent process ...
nevertheless I don't think we have a problem with
schizophrenic processes if they have a somewhat sane
*G* interface/view into both spaces ...
> To allow for migration it must be possible for the pids in
> those pid spaces to be different.
I take that as migration of a 'container' from one
system to another, not as 'migration' between spaces
I don't understand what you mean here, please elaborate
> It is undesirable in the normal case of affairs to allocate more
> than one pid per process.
>
> Given the small range of pid values these constraints make an
> efficient and general pid space solution challenging.
>
> The question:
> If we could add additional pid values in different pid spaces
> to a process with a syscall upon demand would that lead to an
> implementation everyone could use?
again, for what would I need a 'second' or 'third' pid
value for a process either on demand or permanent for
handling or migration?
> I assume most processes by default only have a pid value in
> a single pid space.
>
> The reason I ask is that I believe I know how to implement
> a cheap general mechanism for adding additional pids to a
> process.
I have the feeling this is going into a completely wrong
direction, what am I missing here?
TIA,
Herbert
> Eric
On 3/14/06, Eric W. Biederman <[email protected]> wrote:
> The question:
> If we could add additional pid values in different pid spaces to a
> process with a syscall upon demand would that lead to an
> implementation everyone could use?
Before going into this, how do propose to solve some other issues:
- RT signal contexts have a si_pid field which contains the PID of the
sender. When and how do you fix this up? Can a process which is not
visible in a second PID space send a signal to a process in that
second PID space?
- similar problem: SysV IPC. How do you fix up fields like msg_lspid
in struct msqid_ds?
- the proposed futex extensions for robust and maybe PI mutexes needs
to store the TID in the futex field. If the futex shared by processes
in different PID spaces this value is worthless.
It would perhaps be conceivable to fix up the first two problems in
some cases. If the process is visible in the PID space of the
receiver of the signal or the process which calls msgctl() etc the
kernel could magically fill in the correct PID for the PID space. But
what to do if the process is not visible?
And for the futex case, the kernel is not involved in the fast path.
There is no magic fixup which can happen.
I don't see at all how any of these things can work without breaking
all kinds of code.
"Ulrich Drepper" <[email protected]> writes:
> On 3/14/06, Eric W. Biederman <[email protected]> wrote:
>> The question:
>> If we could add additional pid values in different pid spaces to a
>> process with a syscall upon demand would that lead to an
>> implementation everyone could use?
>
> Before going into this, how do propose to solve some other issues:
>
> - RT signal contexts have a si_pid field which contains the PID of the
> sender. When and how do you fix this up? Can a process which is not
> visible in a second PID space send a signal to a process in that
> second PID space?
>
> - similar problem: SysV IPC. How do you fix up fields like msg_lspid
> in struct msqid_ds?
>
> - the proposed futex extensions for robust and maybe PI mutexes needs
> to store the TID in the futex field. If the futex shared by processes
> in different PID spaces this value is worthless.
Odd. I did not see that in Ingo's patches on the kernel list.
Perhaps only user space cares about storing the tid in the futex
field.
> It would perhaps be conceivable to fix up the first two problems in
> some cases. If the process is visible in the PID space of the
> receiver of the signal or the process which calls msgctl() etc the
> kernel could magically fill in the correct PID for the PID space. But
> what to do if the process is not visible?
>
> And for the futex case, the kernel is not involved in the fast path.
> There is no magic fixup which can happen.
>
> I don't see at all how any of these things can work without breaking
> all kinds of code.
The point of containers and their building blocks largely is isolation
so you can have multiple different user space environments on one
machine. So for most of the pieces that can really confuse user space
the answer is don't do that then. The classic example is pid files
for remembering a daemon is running.
Interactions do need to happen between pid spaces for certain
administrative actions, and as much as possible I don't want
to reinvent the wheel. Pid alases in the kernel are for
that purpose, and so will likely play a role in the RT signal
and the sysv shm case.
Eric
Herbert Poetzl <[email protected]> writes:
> On Tue, Mar 14, 2006 at 11:43:38AM -0700, Eric W. Biederman wrote:
>>
>> To retain any part of the existing unix process management
>> we need some processes that show up in multiple pid spaces.
>
> hmm ... not sure about that, what 'we' need is a way
> to move between pid spaces and to control processes
> in a child space from the parent process ...
The conditional was this is what it takes to reuse the existing
interfaces.
> nevertheless I don't think we have a problem with
> schizophrenic processes if they have a somewhat sane
> *G* interface/view into both spaces ...
>
>> To allow for migration it must be possible for the pids in
>> those pid spaces to be different.
>
> I take that as migration of a 'container' from one
> system to another, not as 'migration' between spaces
Yes.
> I don't understand what you mean here, please elaborate
Basically that in the general case there can be no assumptions
that a pids in one pid space do not conflict with pids in another pids
space.
>> It is undesirable in the normal case of affairs to allocate more
>> than one pid per process.
>>
>> Given the small range of pid values these constraints make an
>> efficient and general pid space solution challenging.
>>
>> The question:
>> If we could add additional pid values in different pid spaces
>> to a process with a syscall upon demand would that lead to an
>> implementation everyone could use?
>
> again, for what would I need a 'second' or 'third' pid
> value for a process either on demand or permanent for
> handling or migration?
Not for migration for things such a ptrace, ioprio, granting of
capabilities or any of the kernel's management operations
Eric