ИМЯ

clone, __clone2 - создать процесс-потомок

ОБЗОР

/* Прототип обёрточной функции glibc */

#define _GNU_SOURCE
#include <sched.h>

int clone(int (*fn)(void *), void *child_stack,
int flags, void *arg, ...
/* pid_t *ptid, void *newtls, pid_t *ctid */ );

/* для прототипа неструктурированного системного вызова, смотрите ЗАМЕЧАНИЯ */

ОПИСАНИЕ

Вызов clone() создаёт новый процесс подобно fork(2).

Здесь описана обёрточная функция glibc clone() и используемый ею системный вызов.
В основном, описывается обёрточная функция;отличия от системного вызова приводятся
в конце данной справочной страницы.

В отличие от fork(2), clone() позволяет процессу-потомку использовать некоторые
части контекста выполнения совместно с вызывающим процессом, например: область
памяти, таблица файловых дескрипторов и таблица обработчиков сигналов. Заметим,
что в данной справочной странице «вызывающий процесс» обычно соответствует
«родительскому процессу». Но см. ниже описание CLONE_PARENT.

Одним из вариантов использования вызова clone() является реализация нитей:
несколько нитей управления в программе, выполняющиеся одновременно в общем
пространстве памяти.

Когда процесс-потомок создаётся с помощью clone(), он запускает функцию fn(arg).
Это отличается от fork(2), где выполнение продолжается в потомке от точки вызова
fork(2). Аргумент fn является указателем на функцию, которая вызывается
процессом-потомком в начале своего выполнения. Аргумент arg передаётся функции fn.

Когда происходит возврат из функции приложения fn(arg) процесс-потомок
завершается. Целое значение, возвращаемое fn, является кодом выхода
процесса-потомка. Процесс-потомок может также быть завершён явным образом с
помощью вызова exit(2) или после получения завершающего сигнала.

Аргумент child_stack задаёт положение стека, используемого процессом-потомком. Так
как процесс-потомок и вызывающий процесс могут использовать общую память,
процесс-потомок не может выполняться в том же стеке, что и вызывающий процесс.
Поэтому вызывающий процесс должен установить пространство памяти для стека
процесса-потомка и передать указатель на это пространство в вызове clone(). Стеки
растут вниз для всех процессоров, на которых работает Linux (за исключением
процессоров HP PA), так что child_stack, обычно, указывает на наибольший адрес в
пространстве памяти, которое устанавливается для стека процесса-потомка.

Младший байт flags содержит номер сигнала завершения, который посылается родителю,
когда работа потомка завершается. Если этот сигнал задаётся как нечто отличное от
SIGCHLD, то родительский процесс должен задать параметр __WALL или __WCLONE при
ожидании завершения работы потомка с помощью вызова wait(2). Если никакой сигнал
не задан, то родительский процесс не извещается сигналом, когда потомок
завершается.
set_tid_address(2). Используется в библиотеках работы с нитями.

CLONE_CHILD_SETTID (начиная с Linux 2.5.49)
Сохранить ID нити потомка, расположенный в ctid в памяти потомка.

CLONE_FILES (начиная с Linux 2.0)
Если задан флаг CLONE_FILES, то вызывающий процесс и процесс-потомок
используют одну и ту же таблицу файловых дескрипторов. Любые файловые
дескрипторы, создаваемые вызывающим процессом или процессом-потомком, также
доступны и в другом процессе. Аналогично, если один из процессов закрывает
файловый дескриптор или изменяет ассоциированные с ним флаги (с помощью
fcntl(2) операцией F_SETFD), то это оказывает влияние и на другой процесс.
Если процесс использующий общую таблицу файловых дескрипторов вызывает
execve(2), то таблица файловых дескрипторов копируется в отдельную (не
общую).

Если флаг CLONE_FILES не задан, то процесс-потомок наследует копии всех
файловых дескрипторов, открытых в вызывающем процессе на момент вызова
clone(). Последующие операции над файловыми дескрипторами по открытию и
закрытию файлов или изменению флагов файловых дескрипторов, выполняемые
вызывающим процессом или процессом-потомком, не оказывают эффекта на другой
процесс. Заметим, что дублируемые файловые дескрипторы в потомке указывают
на те же открытые файловые дескрипторы что и файловые дескрипторы
вызывающего процесса и, таким образом, файловые смещения и флаги состояния
файлов используются совместно (смотрите open(2)).

CLONE_FS (начиная с Linux 2.0)
Если задан флаг CLONE_FS, то вызывающий процесс и процесс-потомок
используют одну и ту же информацию о файловой системе. К ней относится
корневой каталог файловой системы, текущий рабочий каталог и значение
umask. Любой вызов, chroot(2), chdir(2) или umask(2), выполняемый одним
процессом, оказывает влияние и на другой.

Если флаг CLONE_FS не задан, то процесс-потомок работает с копией
информации о файловой системе вызывающего процесса, снятой на момент вызова
clone(). Вызовы chroot(2), chdir(2), umask(2), выполняемые позже одним из
процессов, не оказывают эффект на другой процесс.

CLONE_IO (начиная Linux 2.6.25)
Если задан флаг CLONE_IO, то новый процесс использует общий контекст
ввода-вывода с вызывающим процессом. Если этот флаг не установлен, то (как
и в fork(2)) новый процесс будет иметь свой отдельный контекст
ввода-вывода.

Контекст ввода-вывода — это область ввода-вывода в дисковом планировщике
(т. е. то, что планировщик ввода-вывода использует при планировании
ввода-вывода процесса). Если процессы используют общий контекст
ввода-вывода, то они рассматриваются планировщиком ввода-вывода как один.
Следовательно, они совместно делят время доступа к диску. У некоторых
планировщиков ввода-вывода, если два процесса используют общий контекст
ввода-вывода, то им будет разрешено чередовать доступ к диску. Если
несколько нитей выполняют ввод-вывод из одного процесса (например,
aio_read(3)), то для них нужно указать CLONE_IO для получения большей
производительности ввода-вывода.

Если в ядре не указан параметр сборки CONFIG_BLOCK, то этот флаг ни на что
не влияет.

Только привилегированный процесс (CAP_SYS_ADMIN) может использовать
CLONE_NEWCGROUP.

CLONE_NEWIPC (начиная с Linux 2.6.19)
Если задан флаг CLONE_NEWIPC, то процесс создаётся в новом пространстве
имён IPC. Если этот флаг не установлен, то (как и в fork(2)) процесс
создаётся в том же пространстве имён IPC что и вызывающий процесс. Этот
флаг предназначен для реализации контейнеров.

Пространство имён IPC предоставляет изолированную выборку объектов System V
IPC (смотрите svipc(7)) и (начиная с Linux 2.6.30) очередей сообщений POSIX
(смотрите mq_overview(7)). Общие характеристики этих механизмов IPC в том,
что объекты IPC определяются механизмами, а не путями в файловой системе.

Объекты, созданные в пространстве имён IPC, видимы всем другим процессам,
которые являются членами этого пространства имён, и невидимы процессам из
других пространств имён IPC.

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

Только привилегированный процесс (CAP_SYS_ADMIN) может использовать
CLONE_NEWIPC. Этот флаг нельзя указывать вместе с CLONE_SYSVSEM.

Дополнительную информацию о пространствах имён IPC смотрите в
namespaces(7).

CLONE_NEWNET (начиная с Linux 2.6.24)
(Реализация этого флага завершена только в Linux 2.6.29.)

Если задан флаг CLONE_NEWNET, то процесс создаётся в новом сетевом
пространстве имён. Если флаг не установлен, то (как и в fork(2)), процесс
создаётся в том же сетевом пространстве имён что и вызывающий процесс. Этот
флаг предназначен для реализации контейнеров.

Сетевое пространство имён предоставляет изолированное представление
сетевого стека (интерфейсы сетевых устройств, стеки протоколов IPv4 и IPv6,
таблицы маршрутизации IP, правила межсетевого экрана, дерево каталогов
/proc/net и /sys/class/net, сокеты и т.д.). Физическое сетевое устройство
может находиться только в одном сетевом пространстве имён. Пара виртуальных
сетевых устройств ("veth") предоставляет каналоподобную абстракцию, которую
можно использовать для создания туннелей между сетевыми пространствами имён
и создания моста к физическому сетевому устройству из другого пространства
имён.

Когда сетевое пространство имён высвобождается (т. е., когда завершается
последний процесс в пространстве имён), его физические сетевые устройства
перемещаются обратно в первоначальное сетевое пространство имён (не
родительского процесса). Дополнительную информацию о сетевых пространствах
имён смотрите в namespaces(7).

Только привилегированный процесс (CAP_SYS_ADMIN) может использовать
CLONE_NEWNET.

CLONE_NEWNS (начиная с Linux 2.4.19)
Дополнительную информацию о пространствах имён монтирования смотрите в
namespaces(7) и mount_namespaces(7).

CLONE_NEWPID (начиная с Linux 2.6.24)
Если задан флаг CLONE_NEWPID, то процесс создаётся в новом пространстве
имён PID. Если флаг не установлен, то (как и в fork(2)), процесс создаётся
в том же пространстве имён PID, что и вызывающий процесс. Этот флаг
предназначен для реализации контейнеров.

Дополнительную информацию о пространствах имён PID смотрите в namespaces(7)
и pid_namespaces(7).

Только привилегированный процесс (CAP_SYS_ADMIN) может использовать
CLONE_NEWPID. Этот флаг нельзя указывать вместе с CLONE_THREAD или
CLONE_PARENT.

CLONE_NEWUSER
(Впервые этот флаг приобрёл значение для clone() в Linux 2.6.23, текущая
семантика clone() появилась в Linux 3.5, а оставшиеся части, делающие
пространства имён пользователя полностью работоспособными, включены в Linux
3.8.)

Если задан флаг CLONE_NEWUSER, то процесс создаётся в новом пространстве
имён пользователя. Если флаг не установлен, то (как и в fork(2)), процесс
создаётся в том же пространстве имён пользователя, что и вызывающий
процесс.

Дополнительную информацию о пространствах имён пользователя смотрите в
namespaces(7) и user_namespaces(7).

До Linux 3.8, для использования CLONE_NEWUSER у вызывающего требовалось три
мандата: CAP_SYS_ADMIN, CAP_SETUID и CAP_SETGID. Начиная с Linux 3.8, для
создания пространства имён пользователя никаких привилегий не требуется.

Этот флаг нельзя указывать вместе с CLONE_THREAD или CLONE_PARENT. По
соображениям безопасности, CLONE_NEWUSER нельзя указывать вместе с
CLONE_FS.

Дополнительную информацию о пространствах имён пользователя смотрите в
user_namespaces(7).

CLONE_NEWUTS (начиная с Linux 2.6.19)
Если задан флаг CLONE_NEWUTS, то процесс создаётся в новом пространстве
имён UTS, чьи идентификаторы инициализируются копией идентификаторов из
пространства имён UTS вызывающего процесса. Если флаг не указан, то (как и
в fork(2)), процесс создаётся в том же пространстве имён UTS что и
вызывающий процесс. Этот флаг предназначен для реализации контейнеров.

Пространство имён UTS — это набор идентификаторов, возвращаемых uname(2);
помимо остальных, сюда включены доменное имя и имя узла, которые изменить с
помощью setdomainname(2) и sethostname(2), соответственно. Изменившиеся
идентификаторы в пространстве имён UTS видимы всем остальным процессам в
том же пространстве имён, но не видимы процессам из других пространств имён
UTS.

Только привилегированный процесс (CAP_SYS_ADMIN) может использовать
CLONE_NEWUTS.
вызывающий процесс.

Заметим, что это тот родительский процесс, который возвращается вызовом
getppid(2), и которому приходит сигнал когда потомок завершается, так что
если указан флаг CLONE_PARENT, то сигнал будет посылаться родителю
вызывающего процесса, а не самому вызывающему процессу.

CLONE_PARENT_SETTID (начиная с Linux 2.5.49)
Сохраняет ID нити потомка в расположение ptid в память родителя (в Linux
2.5.32-2.5.48 был флаг CLONE_SETTID, который делал это).

CLONE_PID (устарел)
Если задан флаг CLONE_PID, то процесс-потомок создаётся с таким же
идентификатором процесса (ID) как и вызывающий процесс. Это хорошо для
ковыряния в системе, но не более того. Начиная с 2.3.21 этот флаг может
быть указан только в системном загрузочном процессе (PID 0). Флаг удалён в
Linux 2.5.16. Начиная с этой версии, ядро просто игнорирует его без ошибки.

CLONE_PTRACE (начиная с Linux 2.2)
Если задан флаг CLONE_PTRACE и вызывающий процесс находится в режиме
трассировки, то процесс-потомок также будет работать в режиме трассировки
(см. ptrace(2)).

CLONE_SETTLS (начиная с Linux 2.5.32)
Дескриптор TLS (локальная память нитей) помещается в newtls.

Смысл newtls и его влияние зависит от архитектуры. На x86 newtls
рассматривается как struct user_desc * (смотрите set_thread_area(2)). На
x86_64 это новое значение используется для базового регистра %fs (смотрите
описание значения ARCH_SET_FS в arch_prctl(2)). На архитектурах с отдельным
регистром для TLS это новое значение помещается врегистр.

CLONE_SIGHAND (начиная с Linux 2.0)
Если задан флаг CLONE_SIGHAND, то вызывающий процесс и процесс-потомок
используют одну и ту же таблицу обработчиков сигналов. Если вызывающий
процесс или процесс-потомок вызывают sigaction(2) для изменения поведения
при получении сигнала, то это поведение изменяется также и в другом
процессе. Однако, вызывающий процесс и процесс-потомок имеют различные
маски сигналов и списки ожидающих обработки сигналов. Так, один из них
может блокировать или деблокировать некоторые сигналы, используя
sigprocmask(2), и это не будет влиять на другой процесс.

Если флаг CLONE_SIGHAND не указан, то процесс-потомок наследует копию
обработчиков событий вызывающего процесса, снятую на момент вызова clone().
Вызовы sigaction(2), выполняемые позже одним из процессов, не оказывают
влияния на другой процесс.

Начиная с Linux 2.6.0-test6, flags должен также включать CLONE_VM, если
указан CLONE_SIGHAND.

CLONE_STOPPED (начиная с Linux 2.6.0-test2)
Если указан флаг CLONE_STOPPED, то после создания потомок перейдёт в
состояние останова (как если бы ему послали сигнал SIGSTOP), и начнёт
работу по сигналу SIGCONT.

Этот флаг устарел начиная с Linux 2.6.25 и был удалён в Linux 2.6.38.
Начиная с этой версии, ядро просто игнорирует его без ошибки. Начиная с
то потомок имеет отдельный список semadj, который первоначально пуст.

CLONE_THREAD (начиная с Linux 2.4.0-test8)
Если указан флаг CLONE_THREAD, то потомок размещается в той же группе
нитей, что и вызывающий процесс. Чтобы сделать остаток обсуждения
CLONE_THREAD более понятным, термин «нить» используется для ссылки на
процессы внутри группы нитей.

Группы нитей были добавлены в Linux 2.4 для поддержки нитей POSIX,
описываемых как набор нитей, использующих один и тот же PID. Внутренне
общий PID — это так называемый идентификатор группы нитей (TGID). Начиная с
Linux 2.4, вызов getpid(2) возвращает идентификатор группы нитей
вызывающего процесса.

Внутри группы нити можно различать по их (глобальному) уникальному
идентификатору нити (TID). TID новой нити возвращается вызывающему как
результат clone(), а нить может узнать свой TID с помощью вызова gettid(2).

Когда вызов clone() делается без CLONE_THREAD, то получаемая нить
помещается в новую группу нитей, чей TGID совпадает с TID нити. Эта нить
будет лидером новой группы нитей.

Новая нить, созданная с CLONE_THREAD, имеет тот же родительский процесс что
и вызвавший clone() (т.е., как CLONE_PARENT), поэтому при вызове getppid(2)
возвращается одинаковое значение для всех нитей в группе нитей. Когда нить
CLONE_THREAD завершается, нити, создавшей её с помощью clone(), не
посылается сигнал SIGCHLD (или другой сигнал завершения); состояние такой
нити нельзя получить с помощью wait(2). Про нить говорят, что она
отсоединена (detached).

После завершения работы всех нитей в группе нитей родительскому процессу
группы нитей посылается сигнал SIGCHLD (или другой завершающий сигнал).

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

Если одна из нитей группы нитей создаёт потомка с помощью fork(2), то любая
нить группы может вызвать wait(2) для ожидания этого потомка.

Начиная с Linux 2.5.35, аргумент flags должен также включать CLONE_SIGHAND,
если указан флаг CLONE_THREAD (также заметим, что начиная с Linux
2.6.0-test6, для CLONE_SIGHAND также требуется включать CLONE_VM).

Сигналы могут посылаться как всей группе (т.е., TGID) с помощью kill, так и
заданной нити (т.е., TID) с помощью tgkill(2).

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

Каждая нить имеет свою маску сигналов, задаваемую с помощью sigprocmask(2),
но сигналы могут ожидать обработки: всем процессом (т.е., доставляются всем
членам группы нитей), если посылаются с помощью kill(2); или отдельной
нитью, если посылаются с помощью tgkill(2). Вызов sigpending(2) возвращает
набор сигналов, который представляет собой объединение ожидающих сигналов
для всего процесса и сигналов, которые ожидает вызывающая нить.
Если указан флаг CLONE_UNTRACED, то выполняющий трассировку процесс не
сможет указать CLONE_PTRACE на этом процессе-потомке.

CLONE_VFORK (начиная с Linux 2.2)
Если указан флаг CLONE_VFORK, то выполнение вызывающего процесса
приостанавливается до тех пор, пока потомок не освободит ресурсы
виртуальной памяти с помощь вызова execve(2) или _exit(2) (как с vfork(2)).

Если флаг CLONE_VFORK не указан, то вызывающий процесс и потомок доступны
для планирования после вызова, и приложение не должно полагаться на то, что
выполнение производится в каком-то определённом порядке.

CLONE_VM (начиная с Linux 2.0)
Если задан флаг CLONE_VM, то вызывающий и дочерний процесс работают в одном
пространстве памяти. В частности, запись в память одним процессом видна
другому. Кроме того, выполнение отображения или снятия отображения в
память, выполняемая с помощью mmap(2) или munmap(2), одним процессом,
влияет на другой.

Если флаг CLONE_VM не установлен, то дочерний процесс выполняется в
отдельной копии пространства памяти вызывающего процесс с момента clone().
Запись в память или отображение/снятие отображения файла, выполняемое одним
процессом, не влияет на другой (как с fork(2)).

Отличия между библиотекой C и ядром
Внутренний системный вызов clone больше похож на fork(2) в том плане, что
выполнение в потомке продолжается от места вызова. В связи с этим, аргументы fn и
arg обёрточной функции clone() отсутствуют. Более того, изменён порядок этих
аргументов. Также на разных архитектур есть свои варианты вызова.

Интерфейс внутреннего системного вызова на x86-64 и некоторых других архитектурах
(включая sh, tile и alpha) приблизительно такой:

long clone(unsigned long flags, void *child_stack,
int *ptid, int *ctid,
unsigned long newtls);

На x86-32 и некоторых других распространённых архитектурах (включая score, ARM,
ARM 64, PA-RISC, arc, Power PC, xtensa и MIPS) порядок последних двух аргументов
обратный:

long clone(unsigned long flags, void *child_stack,
int *ptid, unsigned long newtls,
int *ctid);

На архитектурах cris и s390 порядок первых двух аргументов обратный:

long clone(void *child_stack, unsigned long flags,
int *ptid, int *ctid,
unsigned long newtls);

На архитектуре microblaze есть дополнительный аргумент:

long clone(unsigned long flags, void *child_stack,
int stack_size, /* Size of stack */
int *ptid, int *ctid,
unsigned long newtls);

ia64
На ia64 используется другой интерфейс:

int __clone2(int (*fn)(void *),
void *child_stack_base, size_t stack_size,
int flags, void *arg, ...
/* pid_t *ptid, struct user_desc *tls, pid_t *ctid */ );

Прототип, показанный выше, относится к обёрточной функции glibc; в интерфейсе
системного вызова отсутствуют аргументы fn или arg, а также изменён порядок
аргументов: первым аргументом является flags, а последним — tls.

Системный вызов __clone2() работает также как и clone() за исключением того, что
child_stack_base указывает на самый нижний адрес области стека потомка, и в
stack_size задаётся размер стека, указываемого в child_stack_base.

Linux версии 2.4 и более ранние
В Linux 2.4 и более ранних clone() не принимал аргументов ptid, tls и ctid.

ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ

При успешном выполнении в вызывающую исполняемую нить возвращается ID нити
дочернего процесса. Иначе в контекст вызывающего возвращается -1, дочерний процесс
не создаётся и errno устанавливается в соответствующее значение.

ОШИБКИ

EAGAIN Уже выполняется максимальное количество процессов; смотрите fork(2).

EINVAL Указан флаг CLONE_SIGHAND, но нет CLONE_VM (начиная с Linux 2.6.0-test6).

EINVAL Указан флаг CLONE_THREAD, но нет CLONE_SIGHAND (начиная с Linux 2.5.35).

EINVAL Указаны оба флага, CLONE_FS и CLONE_NEWNS, в flags.

EINVAL (начиная с Linux 3.9)
Указаны оба флага, CLONE_NEWUSER и CLONE_FS, в flags.

EINVAL Указаны оба флага, CLONE_NEWIPC и CLONE_SYSVSEM, в flags.

EINVAL Указан один или оба флага, CLONE_NEWPID или CLONE_NEWUSER, и один или оба
флага, CLONE_THREAD или CLONE_PARENT, в flags.

EINVAL Возвращается обёрточной функцией glibc clone(), если fn или child_stack
равны NULL.

EINVAL Указан флаг CLONE_NEWIPC в flags, но ядро собрано без параметров
CONFIG_SYSVIPC и CONFIG_IPC_NS.

EINVAL Указан флаг CLONE_NEWNET в flags, но ядро собрано без параметра
CONFIG_NET_NS.

EINVAL Указан флаг CLONE_NEWPID в flags, но ядро собрано без параметра
CONFIG_PID_NS.

EINVAL Указан флаг CLONE_NEWUTS в flags, но ядро собрано без параметра CONFIG_UTS.

EINVAL Значение child_stack не выровнено по нужной границе для этой архитектуры.
EPERM Указан флаг CLONE_PID, но ID процесса не равен 0.

EPERM Флаг CLONE_NEWUSER указан в flags, но эффективный пользовательский ID или
эффективный ID группы вызывающего не отображён в родительское пространство
имён (смотрите user_namespaces(7)).

EPERM (начиная с Linux 3.9)
В flags был указан флаг CLONE_NEWUSER и вызывающий выполняется в окружении
chroot (т. е. корневой каталог вызывающего не совпадает с корневым
каталогом пространства имён монтирования, в котором он находится).

ERESTARTNOINTR (начиная с Linux 2.6.17)
Системный вызов был прерван сигналом и перезапущен (может быть замечено
только при трассировке).

EUSERS (начиная с Linux 3.11)
Флаг CLONE_NEWUSER указан в flags, и вызов привёл бы к превышению
ограничения на количество вложенных пользовательских пространств имён.
Смотрите user_namespaces(7).

ВЕРСИИ

Вызов clone() отсутствует в libc5. В glibc2 есть clone(), который соответствует
данному описанию.

СООТВЕТСТВИЕ СТАНДАРТАМ

Вызов clone() есть только в Linux и не должен использоваться в переносимых
программах.

ЗАМЕЧАНИЯ

Системный вызов kcmp(2) можно использовать для проверки того, что два процесса
совместно используют различные ресурсы, такие как таблицу файловых дескрипторов,
семафор System V для отмены операций или виртуальное адресное пространство.

Для ядер версий 2.4.x флаг CLONE_THREAD не делает родителем новой нити того же
родителя что и у вызывающего процесса. Однако для ядер версий 2.4.7-2.4.18 флаг
CLONE_THREAD неявно подразумевает флаг CLONE_PARENT (как в ядре 2.6).

Некоторое время существовал флаг CLONE_DETACHED (начиная с 2.5.32): родитель не
хочет получать сигнал завершения потомка. В Linux 2.6.2 необходимость указывать
этот флаг вместе с CLONE_THREAD отпала. Этот флаг ещё определён, но не оказывает
никакого действия.

На архитектуре i386 clone() не должен вызываться через vsyscall, а запускаться
явно с помощью int $0x80.

ДЕФЕКТЫ

Версии библиотеки GNU C, которые включают библиотеку нитей NPTL, содержат
обёрточную функцию getpid(2), которая выполняет кэширование PID. Это кэширование
полагается на поддержку обёртки glibc для clone(), но, согласно имеющейся
реализации, в некоторых случаях кэш может содержать неактуальные данные. В
частности, если сигнал доставляется потомку сразу после вызова clone(), то вызов
getpid(2) в обработчике сигнала может может вернуть PID вызывающего процесса
(«родителя»), если у обёртки clone ещё не было возможности обновить кэш PID в
потомке. (В этом описании не рассматривается случай где потомок был создан с
использованием флага CLONE_THREAD, когда getpid(2) должен вернуть одинаковое
значение и в потомок и в процесс, который вызвал clone(), так как вызывающий и
потомок находятся в одной группе нитей. Также проблема устаревания кэша возникает,

ПРИМЕР

Следующая программа демонстрирует использование clone() для создания дочернего
процесса, который выполняется в отдельном пространстве имён UTS. Потомок изменяет
имя узла в своём пространстве имён UTS. И предок и потомок затем выводят системное
имя узла, чтобы можно было убедиться в неодинаковости пространств имён. Пример
использования этой программы смотрите в setns(2).

Исходный код программы
#define _GNU_SOURCE
#include <sys/wait.h>
#include <sys/utsname.h>
#include <sched.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
} while (0)

static int /* Начало функции клонированного
потомка */
childFunc(void *arg)
{
struct utsname uts;

/* Изменяем имя узла в пространстве имён UTS потомка */

if (sethostname(arg, strlen(arg)) == -1)
errExit("sethostname");

/* Получаем и показывает имя узла */

if (uname(&uts) == -1)
errExit("uname");
printf("uts.nodename in child: %s\n", uts.nodename);

/* Перед сном оставим пространство имён открытым.
Это позволяет поэкспериментировать — например, другой
процесс может подключиться к пространству имён. */

sleep(200);

return 0; /* Завершение работы потомка */
}

#define STACK_SIZE (1024 * 1024) /* Размер стека клонированного
потомка */

int
main(int argc, char *argv[])
{
char *stack; /* Начало буфера стека */
char *stackTop; /* Конец буфера стека */
pid_t pid;
struct utsname uts;

errExit("malloc");
stackTop = stack + STACK_SIZE; /* Считаем, что стек растёт вниз */

/* Создаём потомка с собственным пространством имён UTS;
потомок начинает выполнение с childFunc() */

pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
if (pid == -1)
errExit("clone");
printf("clone() returned %ld\n", (long) pid);

/* Предок попадает сюда */

sleep(1); /* Даём время потомку изменить своё имя узла */

/* Показываем имя узла в пространстве имён UTS предка. Оно будет
отличаться от имени узла в пространстве имён UTS потомка. */

if (uname(&uts) == -1)
errExit("uname");
printf("uts.nodename in parent: %s\n", uts.nodename);

if (waitpid(pid, NULL, 0) == -1) /* Ждём потомка */
errExit("waitpid");
printf("child has terminated\n");

exit(EXIT_SUCCESS);
}

СМОТРИТЕ ТАКЖЕ

fork(2), futex(2), getpid(2), gettid(2), kcmp(2), set_thread_area(2),
set_tid_address(2), setns(2), tkill(2), unshare(2), wait(2), capabilities(7),
namespaces(7), pthreads(7)