Re: [Qemu-devel] [PATCH] Fix vfork() syscall emulation

["Kirill A. Shutemov" <kirill@shutemov.name>]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

On Sat, Sep 20, 2008 at 02:45:57PM +0200, andrzej zaborowski wrote:
> 2008/9/20 Kirill A. Shutemov <kirill@shutemov.name>:
> > On Sat, Sep 20, 2008 at 04:56:45AM +0200, andrzej zaborowski wrote:
> >> 2008/9/18 Kirill A. Shutemov <kirill@shutemov.name>:
> >> > vfork() is a kind of fork, not thread despite CLONE_VM
> >>
> >> According to clone(2) it can be either, the only difference is that
> >> vfork() suspends the parent process.  So if CLONE_VM is set, I think
> >> still the pthread / clone way should be used and the child thread
> >> should be waited on.
> >
> > vfork() suspends the parent process until a call of execve(2) or _exit(2).
> > If child call execnv(2) it replaces whole process, not only the thread.
> > If child call _exit(2) it stops while process, not only the thread.
> 
> Do you mean that's the current behavior in qemu?  That's not what clone(2) says.

Currently, qemu with NPTL(I've tested on ARM EABI) on CLONE_VM create
thread using pthread interface. Every thread has its own stack.

vfork() is clone() with flags CLONE_VM and CLONE_VFORK. 

man vfork(2):

   Linux Description
       vfork(),  just  like  fork(2), creates a child process of the calling
       process.  For details and return value and errors, see fork(2).

       vfork() is a special case of clone(2).  It is used to create new pro-
       cesses without copying the page tables of the parent process.  It may
       be useful in performance sensitive applications where a child will be
       created which then immediately issues an execve(2).

       vfork()  differs  from  fork(2) in that the parent is suspended until
       the child makes a call to execve(2) or _exit(2).   The  child  shares
       all  memory  with its parent, including the stack, until execve(2) is
       issued by the child.  The child must  not  return  from  the  current
       function or call exit(3), but may call _exit(2).

       Signal handlers are inherited, but not shared.  Signals to the parent
       arrive after the child releases the parent's memory.

So, implementation vfork() using pthread is wrong.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]