[PATCH] Add a choosepid() syscall as a simpler alternative to clone_with_pids()

[Serge E. Hallyn]

Quoting Oren Laadan (orenl at librato.com):
> 
> 
> Dan Smith wrote:
> > This proposed simpler interface builds on all the real work done by Suka's
> > early patches in his clone3() set.  Instead of passing in the pids we want
> > in the clone3() call itself, this interface lets us build that list ahead
> > of time, to be used on the next regular clone().
> > 
> > Some points about the implementation:
> >  - The first call to choosepid() allocates a pid_t array on current
> >  - All pids in that list start as zero, which do_fork_with_pids treats as
> >    undefined
> >  - A call to clone() or exec() always clears the current set of next pids
> >  - This was Serge's idea, based on a permutation of Daniel Lezcano's
> >    cloneat() suggestion
> >  - This is based on all Suka's hard work, with a trivial change to the
> >    do_fork_with_pids() function to eliminate the copy_from_user() of the
> >    pid_t list
> > 
> > Signed-off-by: Dan Smith <danms at us.ibm.com>
> > Acked-by: Serge Hallyn <serue at us.ibm.com>
> 
> I don't recall the details, but you probably wanna look at how/when
> kernel threads are created and also at usermode helpers created from
> the kernel (e.g. to load a module on-demand) - make sure they don't
> intentionally (or not) consume the nextpid prepared by the program.

Yup, great point.  Looks like we would want to check for usermode(regs)
and, if that's false, then pass in NULL for target_pids (either from
do_fork_with_pids to copy_process, or from copy_process to alloc_pid()).

-serge