CLONE_PARENT in a container

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.

Oren Laadan [[email protected]] 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

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