[PATCH 1/7] vfork: Fix flags when using clone syscall

[Vineet Gupta]

Hi Rich,

On Monday 11 March 2013 07:01 PM, Markos Chandras wrote:
> On 11 March 2013 13:21, Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
>> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
>> Cc: Markos Chandras <markos.chandras at imgtec.com>
>> ---
>>  libc/sysdeps/linux/common/vfork.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/libc/sysdeps/linux/common/vfork.c b/libc/sysdeps/linux/common/vfork.c
>> index a85156d..c4ebe1f 100644
>> --- a/libc/sysdeps/linux/common/vfork.c
>> +++ b/libc/sysdeps/linux/common/vfork.c
>> @@ -13,10 +13,11 @@ extern __typeof(vfork) __vfork attribute_hidden;
>>  # if defined __NR_clone && !defined __NR_vfork
>>  # include <signal.h>
>>  # include <sys/types.h>
>> +# include <sys/sched.h>        /* CLONE_* */
>>
>>  pid_t __vfork(void)
>>  {
>> -       pid_t pid = INLINE_SYSCALL(clone, 4, SIGCHLD,
>> +       pid_t pid = INLINE_SYSCALL(clone, 4, (CLONE_VM|CLONE_VFORK|SIGCHLD),
>>                                    NULL, NULL, NULL);
>>
>>         if (pid < 0)
>> --
>> 1.7.4.1
>>
>> _______________________________________________
>> uClibc mailing list
>> uClibc at uclibc.org
>> http://lists.busybox.net/mailman/listinfo/uclibc
> Hi Vineet,
>
> It was suggested to use only the SIGCHLD flag for clone. See
> http://lists.uclibc.org/pipermail/uclibc/2012-November/047161.html
> and
> http://lists.uclibc.org/pipermail/uclibc/2012-November/047277.html

IMHO, the reasoning in those discussions is flawed. I agree that any "C"
implementation of vfork is dubious - because there is no gaurantee that stack
won't be clobbered when the vfork wrapper returns (unless arch has a Branch-n-link
reg and this function simply uses that to return w/o touching the stack).
However if the orig code vfork based "C" version existed it meant that some arch
could use it. By changing it to use clone syscall with  CLONE_VM | CLONE_VFORK |
SIGCHLD we are simply changing the mechanism but with same semantics. Making it
behave like fork is a semantical change.

Note that even on MMU system - Busybox init uses vfork for certain cases to
guarantee that parent only runs after child has exited - something which fork
can't guarantee.

And further, if an arch doesn't/can't use the common vfork.c it needs to define
it's own vfork.S - but we can't make the generic definition semantically wrong.

-Vineet