Re: clone(2)

[vijay nag <vijunag at gmail dot com>]

On Thu, Dec 19, 2013 at 1:50 AM, Ángel González <keisial@gmail.com> wrote:
> TL;DR: You need to provide child_stack.
>
>
> On 18/12/13 19:14, vijay nag wrote:
>>
>> Hello,
>>
>> I want to create a new process using clone(2) system call.  The
>> clone(2) is invoked the following way "clone(NULL, NULL, SIGCHLD |
>> CLONE_PARENT, NULL);" and seems to be returning EINVAL.  I RTFM of
>> clone(2) which suggested me to use NULL for child_stack when creating
>> a new task. It also suggests that EINVAL is returned when child_stack
>> argument is NULL. I'm little bit confused about its usage. Can someone
>> illustrate a simple invocation of clone(2) for creating a child task ?
>
> The man page mentions two things: the clone() method provided by libc and
> the raw syscall interface which differs slightly. You are only interested in
> the first one, and it doesn't allow a NULL child_stack.
>
>
>
>> Excerpts from man for sys_clone
>>
>> "Another difference for sys_clone is that the child_stack argument may
>> be zero, in which case copy-on-write semantics ensure that the child
>> gets separate copies of stack pages when either process modifies the
>> stack. In this case, for correct operation, the CLONE_VM option should
>> not be specified."
>
> This is at the «The raw system call interface» section, and is comparing the
> clone syscall (let's call it sys_clone) to clone(). So ignore this section.
>
>
>
>> EINVAL
>>
>> Returned by clone() when a zero value is specified for child_stack.
>
>
>
> Finally, there's anothe relevant to child_stack (maybe it's missing in your
> version of the man page).
>>
>>        The  child_stack  argument specifies the location of the stack used
>> by the child process.  Since the child and calling process may share memory,
>> it is not possible for the child
>>        process to execute in the same stack as the calling process.  The
>> calling process must therefore set up memory space for the child stack and
>> pass a  pointer  to  this  space  to
>>        clone().   Stacks  grow  downward on all processors that run Linux
>> (except the HP PA processors), so child_stack usually points to the topmost
>> address of the memory space set up
>>        for the child stack.
>
>
>
> Merry Christmas

Since I don't intend to create a separate stack for N number of cloned
children, that leaves me with the option of directly calling syscall
for __NR_clone and bypassing glibc. Of all the possible optimizations,
glibc has chosen to optimize calls to tiny getXXX() system calls. The
reason why I replaced sys_clone with glibc clone(2) was to get
consistent results from getpid() in the cloned task.  Bypassing glibc
clone(2) results in window time during which getpid() returns parent's
pid till the cache gets updated. I'm left with following options to
safely call syscall for __NR_clone i.e

1) Write a wrapper for clone that does syscall for __NR_clone and
updates the cache in glibc ?
     If this is a plausible approach, what is the way to invalidate the cache ?

2) Is it possible to disable NPTL optimizations for getXXX() in glibc  ?