Re: [RFC][PATCH 7/7][v2] Define clone_with_pids syscall

[Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

Oren Laadan [orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org] wrote:

| > | I should have mentioned earlier, but there is also the case of
| > | CLONE_NEWPID. If CLONE_NEWPID is given, then @nesting should be
| > | plus one, _and_ the corresponding pid must be 1 or 0.
| > 
| > Right. do_fork_with_pids() checks if CLONE_NEWPID is specified with
| > target_pids and returns -EINVAL for now.
| 
| Any reason not to handle this case already ?

The only reason was that we are not planning on supporting C/R of
nested containers for a while, but yes, we don't need to restrict
clone_with_pids().

| 
| I have a simpler suggestion than above: pass the clone_flags to
| copy_target_pids(), and in there, if CLONE_NEWPID is set, then
| you should allocate an array +1 in size, and force last slot to
| be 0 (or 1). User doesn't have to pass a larger array.

Looks like it would be cleaner code-wise, to always allocate an
extra element in the target_pids list and leave the last one set
to 0. If CLONE_NEWPID is set, alloc_pid() will assign the first pid
in the new namespace. If it is not set, the last element will never
be referenced in alloc_pid().