[LTP] Query: Adding support for clone3()

[LTP] Query: Adding support for clone3()

[Viresh Kumar]

Hey guys,

I was looking to start implementation of clone3() syscall in LTP
and am a bit confused here and need your help in doing the same.

LTP abstracts the call to clone() syscall in lib/cloner.c and the current
prototype of it looks like this.

       int clone(int (*fn)(void *), void *stack, int flags, void *arg, ...
                 /* pid_t *parent_tid, void *tls, pid_t *child_tid */ );

One of the challenges with the implementation of clone3() is that
there is no glibc wrapper available. And in case of clone() glibc
wrapper isn't ordinary as it takes care of calling fn() and handling
few stack related things, apart from calling the real syscall.

I am confused now on how should I write support for clone3().

Any suggestions will be appreciated. Thanks.

--
viresh

[LTP] Query: Adding support for clone3()

[Cyril Hrubis]

Hi!
> I was looking to start implementation of clone3() syscall in LTP
> and am a bit confused here and need your help in doing the same.
> 
> LTP abstracts the call to clone() syscall in lib/cloner.c and the current
> prototype of it looks like this.
> 
>        int clone(int (*fn)(void *), void *stack, int flags, void *arg, ...
>                  /* pid_t *parent_tid, void *tls, pid_t *child_tid */ );

This function is there mostly for implementation of container testscases
so that they does not need to deal with the clone() syscall complexity.

> One of the challenges with the implementation of clone3() is that
> there is no glibc wrapper available. And in case of clone() glibc
> wrapper isn't ordinary as it takes care of calling fn() and handling
> few stack related things, apart from calling the real syscall.
> 
> I am confused now on how should I write support for clone3().
> 
> Any suggestions will be appreciated. Thanks.

Let's just add the code into lapi/clone.h, would that work for you?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] Query: Adding support for clone3()

[Viresh Kumar]

On 28-02-20, 09:58, Cyril Hrubis wrote:
> Hi!
> > I was looking to start implementation of clone3() syscall in LTP
> > and am a bit confused here and need your help in doing the same.
> > 
> > LTP abstracts the call to clone() syscall in lib/cloner.c and the current
> > prototype of it looks like this.
> > 
> >        int clone(int (*fn)(void *), void *stack, int flags, void *arg, ...
> >                  /* pid_t *parent_tid, void *tls, pid_t *child_tid */ );
> 
> This function is there mostly for implementation of container testscases
> so that they does not need to deal with the clone() syscall complexity.

Right.

> > One of the challenges with the implementation of clone3() is that
> > there is no glibc wrapper available. And in case of clone() glibc
> > wrapper isn't ordinary as it takes care of calling fn() and handling
> > few stack related things, apart from calling the real syscall.
> > 
> > I am confused now on how should I write support for clone3().
> > 
> > Any suggestions will be appreciated. Thanks.
> 
> Let's just add the code into lapi/clone.h, would that work for you?

Which code are you talking about ?

Here is some stuff about the glibc wrapper for clone() from an stackoverflow
page [1]:

clone(void (*fn)(void *), void *stack_pointer)
{
    push fn onto stack_pointer
    syscall_clone()
    if (child) {
        pop fn off of stack
        fn();
        exit();
    }
}

This takes care of calling fn() and doing some stack related stuff.
The kernel syscall doesn't expect the fn() argument but only the
userspace calls do. How should I handle the extra stuff that userspace
expects for a clone() call ?

-- 
viresh

[1] https://stackoverflow.com/questions/18904292/is-it-true-that-fork-calls-clone-internally

[LTP] Query: Adding support for clone3()

[Cyril Hrubis]

Hi!
> > > One of the challenges with the implementation of clone3() is that
> > > there is no glibc wrapper available. And in case of clone() glibc
> > > wrapper isn't ordinary as it takes care of calling fn() and handling
> > > few stack related things, apart from calling the real syscall.
> > > 
> > > I am confused now on how should I write support for clone3().
> > > 
> > > Any suggestions will be appreciated. Thanks.
> > 
> > Let's just add the code into lapi/clone.h, would that work for you?
> 
> Which code are you talking about ?
> 
> Here is some stuff about the glibc wrapper for clone() from an stackoverflow
> page [1]:
> 
> clone(void (*fn)(void *), void *stack_pointer)
> {
>     push fn onto stack_pointer
>     syscall_clone()
>     if (child) {
>         pop fn off of stack
>         fn();
>         exit();
>     }
> }
> 
> This takes care of calling fn() and doing some stack related stuff.
> The kernel syscall doesn't expect the fn() argument but only the
> userspace calls do. How should I handle the extra stuff that userspace
> expects for a clone() call ?

That depends I guess mostly on the clone() flags, right? Unless we pass
CLONE_VM the child lives in a separate copy of the memory space and we
do not have to do anything about the stack.

So for the most clone3() tests we can just need the struct clone_args
and the syscall number and we can treat it mostly like more complex
version of fork(), i.e. pass NULL and 0 for the stack and stack_size
parameters.

So I would start by adding the kernel version of the clone3() syscall,
the structure, and the V0 structure size into the lapi header and use
that for a basic testcases.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] Query: Adding support for clone3()

[Viresh Kumar]

On 28-02-20, 12:48, Cyril Hrubis wrote:
> That depends I guess mostly on the clone() flags, right? Unless we pass
> CLONE_VM the child lives in a separate copy of the memory space and we
> do not have to do anything about the stack.
> 
> So for the most clone3() tests we can just need the struct clone_args
> and the syscall number and we can treat it mostly like more complex
> version of fork(), i.e. pass NULL and 0 for the stack and stack_size
> parameters.
> 
> So I would start by adding the kernel version of the clone3() syscall,
> the structure, and the V0 structure size into the lapi header and use
> that for a basic testcases.

Okay, so you are suggesting here to create a separate
testcases/kernel/syscalls/clone3 directory for the tests ? That makes
sense as a user may want to test both clone and clone3 on a platform
for a given kernel version.

-- 
viresh