Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Greg <gkurz@fr.ibm.com>]

Eric W. Biederman wrote:
> Greg <gkurz@fr.ibm.com> writes:
> 
> 
>>Eric W. Biederman wrote:
>>
>>>On this front I have been planning on using sys_clone as it allows
>>>pieces of the virtualization to be incrementally built, it already
>>>supports the FS namespace, and it supports flexibly specifying what
>>>you want to contain.
>>>
>>
>>What would you do to handle the following case:
>>
>>pid = getpid();
>>if (sys_clone(CLONE_CONTAINER) == 0) {
>>	ppid = getppid();
>>	assert(ppid == pid);
>>}
>>
>>Most of the calls involving resource ids will return values that aren't
>>*consistent* with ids already stored in userland... could possibly break some
>>piece of code. Perhaps a sys_exec() should also be enforced to reset the process
>>memory.
> 
> 
> Well that assertion will fail.
> At that point getppid() will return 0, and getpid() will return 1.
> 
> Processes getting confused is their own problem.
> 

This flavour of clone should be used with great care then since it breaks the
usual unix process semantics. :)

> Now there will be a pid that the parent sees that will not be 0.
> And that is what the parent will see in the context of wait.
> 
> In my code I introduced a wid (wait id) for that purpose.
> 

Is it possible to see the code ?

> This makes it possible to manage a container using the usual unix
> process semantics.  Which is very important.
> 
> 
> Eric
> 

Thanks.

-Greg-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/