[PATCH v2] Add an internal wrapper for clone, clone2 and clone3

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Feb 15, 2021 at 6:56 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 15/02/2021 07:44, Florian Weimer via Libc-alpha wrote:
> > * H. J. Lu via Libc-alpha:
> >
> >> The clone3 system call provides a superset of the functionality of clone
> >> and clone2.  It also provides a number of API improve ments, including
> >> the ability to specify the size of the child's stack area which can be
> >> used by kernel to compute the shadow stack size when allocating the
> >> shadow stack.  Add:
> >>
> >> extern int __clone_internal (struct clone_args *cl_args, size_t size,
> >>                           int (*__fn) (void *__arg), void *__arg);
> >>
> >> to provide an abstract interface for clone, clone2 and clone3.
> >>
> >> 1. Simplify stack management for clone by passing stack base and size
> >> to __clone_internal.
> >> 2. Consolidate clone vs clone2 differences into a single file.
> >> 3. Use only __clone_internal to clone a thread.  If clone3 returns -1
> >> with ENOSYS, __clone_internal will fall back to clone or clone2.
> >> 4. Add the x86-64 clone3 wrapper.
> >> 5. Enable the public clone3 wrapper in the future after it has been
> >> added to add targets.
> >
> > What do you think about providing a clone wrapper which reuses the
> > caller's stack?  That would be useful for a (v)fork-style clone.  This
> > variant could also be exported because the callback inherits a
> > semi-valid TCB in this case.
> I have this one as a TODO to improve the posix_spawn.

Here is the v2 patch:

1. Update the stack size field, instead of the stack field, passed to
clone3.

OK for master?

Thanks.


-- 
H.J.