* CLONE_PARENT in a container
@ 2009-03-19 22:32 Oren Laadan
[not found] ` <49C2C819.4070802-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Oren Laadan @ 2009-03-19 22:32 UTC (permalink / raw)
To: Linux Containers
What happens when a container-init calls clone() with the
CLONE_PARENT flag set ?
Since CLONE_PARENT can be used to create a sibling, I'd
think that this will create a sibling, in particular, a
new task in the same container whose parent is the parent
of the container. From a quick look in the code I can't
see why this would be impossible.
Is this so ? Is this the desired behavior ?
Oren.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CLONE_PARENT in a container
[not found] ` <49C2C819.4070802-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
@ 2009-03-20 2:07 ` Sukadev Bhattiprolu
[not found] ` <20090320020749.GA31179-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Sukadev Bhattiprolu @ 2009-03-20 2:07 UTC (permalink / raw)
To: Oren Laadan; +Cc: Linux Containers, Oleg Nesterov, Eric W. Biederman
Cc: Oleg, Eric
Oren Laadan [orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org] wrote:
|
| What happens when a container-init calls clone() with the
| CLONE_PARENT flag set ?
|
| Since CLONE_PARENT can be used to create a sibling, I'd
| think that this will create a sibling, in particular, a
| new task in the same container whose parent is the parent
| of the container. From a quick look in the code I can't
| see why this would be impossible.
|
| Is this so ? Is this the desired behavior ?
Good question. CLONE_PARENT was discussed recently on lkml but did
not look obvious to me who uses it or what the semantics are.
Some observations.
- the "reaper" for this sibling would be the reaper of the
parent container, not the init of the new container.
- if container-init exits, this sibling will also be killed since
it has a pid in this container.
Not sure if it needs to be prevented though. An using CLONE_PARENT
may want to run as a container-init :-) And if CLONE_PARENT is used
with CLONE_THREAD, we don't want to preclude threaded container-inits.
Sukadev
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CLONE_PARENT in a container
[not found] ` <20090320020749.GA31179-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
@ 2009-03-20 3:25 ` Eric W. Biederman
0 siblings, 0 replies; 3+ messages in thread
From: Eric W. Biederman @ 2009-03-20 3:25 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: Linux Containers, Oleg Nesterov
Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> writes:
> Cc: Oleg, Eric
>
> Oren Laadan [orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org] wrote:
> |
> | What happens when a container-init calls clone() with the
> | CLONE_PARENT flag set ?
> |
> | Since CLONE_PARENT can be used to create a sibling, I'd
> | think that this will create a sibling, in particular, a
> | new task in the same container whose parent is the parent
> | of the container. From a quick look in the code I can't
> | see why this would be impossible.
> |
> | Is this so ? Is this the desired behavior ?
>
> Good question. CLONE_PARENT was discussed recently on lkml but did
> not look obvious to me who uses it or what the semantics are.
> Some observations.
>
> - the "reaper" for this sibling would be the reaper of the
> parent container, not the init of the new container.
>
> - if container-init exits, this sibling will also be killed since
> it has a pid in this container.
>
> Not sure if it needs to be prevented though. An using CLONE_PARENT
> may want to run as a container-init :-) And if CLONE_PARENT is used
> with CLONE_THREAD, we don't want to preclude threaded container-inits.
Fascinating. We have a way of generating processes that breaks the unix
process tree.
In the initial pid namespace a init that calls CLONE_PARENT will be the
reaper of that child, because the idle thread is in the same pid namespace.
I hadn't even thought about CLONE_PARENT in the context of a pid namespace.
CLONE_PARENT is a rare uncommon case a left over from the first experiments of
threading in linux. So I would not work hard at getting it to do the right thing.
If it is a problem I would kill it.
However if we can support processes who don't have init as their parent it makes
entering a pid namespace a much more realistic proposition.
Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-03-20 3:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-19 22:32 CLONE_PARENT in a container Oren Laadan
[not found] ` <49C2C819.4070802-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-03-20 2:07 ` Sukadev Bhattiprolu
[not found] ` <20090320020749.GA31179-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-20 3:25 ` Eric W. Biederman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.