sys_vfork  [arch/i386/kernel/process.c]


Create a child process and blocks parent.

sys_vfork is a special case of sys_clone. It is used to create new processes 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 sys_execve.

sys_vfork differs from sys_fork in that the parent is suspended until the child makes a call to sys_execve or sys_exit. The child shares all memory with its parent, including the stack, until sys_execve is issued by the child. The child must not return from the current function, but may call sys_exit.

sys_fork is implemented using copy-on-write pages, so the only penalty incurred by sys_fork is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child. However, in the bad old days sys_fork would require making a complete copy of the caller's data space, often needlessly, since usually immediately afterwards a sys_execve is done. Thus, for greater efficiency, BSD introduced the sys_vfork system call, that did not fully copy the address space of the parent process, but borrowed the parent's memory and thread of control until a call to sys_execve or an exit occurred. The parent process was suspended while the child was using its resources. The use of sys_vfork was tricky: for example, not modifying data in the parent process depended on knowing which variables are held in a register.

Arguments

eax 190

Return values

If the system call succeeds the return value is 0.
If the system call fails the return value is one of the following errno values:

-EAGAIN Cannot allocate sufficient memory to copy the parent's page tables and allocate a task structure for the child.
-or-
It was not possible to create a new process because the caller's RLIMIT_NPROC resource limit was encountered. To exceed this limit, the process must have either the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capability.
-ENOMEM Failed to allocate the necessary kernel structures because memory is tight.

Remarks

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

Compatibility

n/a