Описание в стандарте¶

(Из POSIX) Функция vfork() аналогична fork(2) за тем исключением, что поведение не определено, если процесс, созданный vfork(), изменяет любые данные, кроме переменной типа pid_t, используемой в качестве значения, возвращаемого vfork(), или возвращается из функции, из которой была вызвана функция vfork(), или вызывает любую функцию до удачного исполнения _exit(2) или одной из функций семейства exec(3).

Описание в Linux¶

vfork(), так же как и fork(2), создаёт дочерний процесс для вызывающего процесса. Подробности, возвращаемые значения и ошибки смотрите в fork(2).

vfork() — это специальный вариант clone(2). Он используется для создания новых процессов без копирования таблиц страниц родительского процесса. Это может использоваться в приложениях, критичных к производительности, для создания дочерних процессов, сразу же запускающих execve(2).

Вызов vfork() отличается от fork(2) тем, что вызывающая нить блокируется до тех пор, пока не завершится потомок (обычно, вызовом _exit(2) или, что ненормально, из-за принятого необработанного сигнала) или не выполнит execve(2). До этих пор потомок имеет общую память с родителем, включая стек. Потомок не должен выходить из текущей функции или вызывать exit(3) (что приводит к вызовы обработчиков выхода, настроенных родительским процессом и сбрасывает буферы stdio(3) родителя), но может вызвать _exit(2).

Как и у fork(2), дочерний процесс, созданный vfork(), наследует копии различных атрибутов вызвавшего процесса (например, дескрипторы файлов, обработчики сигналов и текущий рабочий каталог); вызов vfork() отличается только в применении виртуального адресного пространства (как описывалось выше).

Сигналы передаются родителю после того, как потомок разблокирует его память (т.е. после того, как потомок завершится или вызовет execve(2)).

Историческое описание¶

В Linux вызов fork(2) реализован при помощи страниц, «копируемых при записи» (copy-on-write), поэтому единственная задержка, возникающая при вызове fork(2) — это время, необходимое для создания копии таблиц страниц родительского процесса и уникальной структуры описания задачи дочернего процесса. Однако, в прошлом для fork(2) могло требоваться создание полной копии пространства данных вызывающего процесса, что часто было ненужно, так как в потомке сразу следовал запуск функции exec(3). Поэтому для большей эффективности в BSD был предложен системный вызов vfork(), который не копировал адресное пространство процесса, а использовал то же самое пространство и управления нитью, блокируя родительский процесс до вызова execve(2) или до прекращения работы потомка. Родительский процесс останавливался до тех пор, пока потомок использовал его ресурсы. Использование vfork() было ненадёжно: например, сохранность данных родительского процесса зависела от того, хранились ли на тот момент переменные в регистрах.

Предостережения¶

Потомок не должен изменять память не ожидаемым образом, так как такие изменения будут видны родительскому процессу после завершения потомка или выполнении другой программы. При таком отношении особенно остро стоит проблема в обработчиках сигналов: если обработчик сигналов, вызванный в потомке (созданном vfork()), изменяет память, то эти изменения могут привести к нарушению целостности состояния процесса с точки зрения родителя (например, изменения памяти были бы видны родителю, а изменения состояния открытых файловых дескрипторов не видны).

Если vfork() вызывается многонитиевом процессе, то в ожидании завершения процесса или запуска новой программы приостанавливается только вызывающая нить. Это означает, что потомок совместно использует адресное пространство другим выполняющимся кодом. Это может быть опасно, если другая нить в родительском процессе изменяет полномочия (с помощью setuid(2) и подобных), так как теперь есть два процесса с разным уровнем прав, выполняемых в одном адресном пространстве. Как пример представим, что многонитиевая программа, работающая с правами суперпользователя, создаёт потомка с помощью vfork(). После vfork() нить в родительском процессе понижает права процесса до непривилегированных, чтобы выполнить некий недоверенный код (например, модуль, открытый через dlopen(3)). В этом случае появляется уязвимость, если родительский процесс использует mmap(2) для отображения кода, то он будет выполнен в привилегированном дочернем процессе.

Замечания, касающиеся Linux¶

Обработчики fork, установленные с помощью pthread_atfork(3), не вызываются когда многонитиевая программа использует вызовы библиотеки нитей NPTL vfork(). Обработчики fork вызываются в этом случае в программе, в которой используется библиотека нитей LinuxThreads. (См. в pthreads(7) описание библиотек нитей Linux.)

Вызов vfork() эквивалентен вызову clone(2) со следующим значением flags:

CLONE_VM | CLONE_VFORK | SIGCHLD

История¶

Системный вызов vfork() впервые появился в 30BSD. В 4.4BSD он стал синонимом fork(2), но в NetBSD он был введён снова; смотрите http://www.netbsd.org/Documentation/kernel/vfork.html. В Linux этот системный вызов был эквивалентом fork(2), примерно, до ядра 2.2.0-pre6. Начиная с 2.2.0-pre9 (на i386 и немного позже на других архитектурах), он стал независимым системным вызовом. Его поддержка была добавлена в glibc 2.0.112.