ОБЗОР

/* Прототип обёрточной функции glibc */
#include <sched.h>
int clone(int (*fn)(void *), void *child_stack,
int flags, void *arg, ...
/* pid_t *ptid, struct user_desc *tls, pid_t *ctid */ );
/* Прототип неструктурированного системного вызова */
long clone(unsigned long flags, void *child_stack,
void *ptid, void *ctid,
struct pt_regs *regs);

Требования макроса тестирования свойств для обёрточной функции glibc (см. feature_test_macros(7)):

clone():

Начиная с glibc 2.14:

_GNU_SOURCE

До glibc 2.14: _BSD_SOURCE || _SVID_SOURCE
    /* также достаточно _GNU_SOURCE */

ОПИСАНИЕ

Здесь описана обёрточная функция 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). Если никакой сигнал не задан, то родительский процесс не извещается сигналом, когда потомок завершается.

Аргумент flags состоит из одной или более данных ниже констант, которые складываются по правилам битового сложения (OR). Флагами задаёт что будет общим между вызывающим процессом и процессом-потомком:

CLONE_CHILD_CLEARTID (начиная с Linux 2.5.49)

Стирать идентификатор (ID) нити потомка, расположенный в ctid в памяти потомка, если потомок существует, и активизировать futex по этому адресу. Соответствующий адрес может быть изменён системным вызовом 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, то этот флаг ни на что не влияет.

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)

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

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

Только привилегированный процесс (имеющий мандат CAP_SYS_ADMIN) может использовать CLONE_NEWNS. Не допускается совместное использование флагов CLONE_NEWNS и CLONE_FS в одном вызове clone().

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.

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

CLONE_PARENT (начиная с Linux 2.3.12)

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

Если флаг CLONE_PARENT не задан, то (как и в fork(2)) родителем будет вызывающий процесс.

Заметим, что это тот родительский процесс, который возвращается вызовом 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)

Аргумент newtls содержит новый дескриптор TLS (локальная память нитей). (См. set_thread_area(2).)

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. Начиная с этой версии, ядро просто игнорирует его без ошибки.

CLONE_SYSVSEM (начиная с Linux 2.5.10)

Если указан флаг CLONE_SYSVSEM, то потомок и вызывающий процесс будут иметь общий единый список значений регулировки семафоров System V (semadj) (смотрите semop(2)). В этом случае общий список накапливает значения semadj из общего списка процессов и регулировки семафоров выполняются только когда завершается последний процесс, использующий общий список (или перестаёт пользоваться общим списком с помощью unshare(2)). Если этот флаг не указан, то потомок имеет отдельный список 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) возвращает набор сигналов, который представляет собой объединение ожидающих сигналов для всего процесса и сигналов, которые ожидает вызывающая нить.

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

CLONE_UNTRACED (начиная с Linux 2.5.46)

Если указан флаг 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 и ядром

long clone(unsigned long flags, void *child_stack,
           void *ptid, void *ctid,
           struct pt_regs *regs);

На некоторых архитектурах порядок аргументов системного вызова отличается от представленного выше. На архитектурах score, microblaze, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa и MIPS четвёртый и пятый аргумент переставлены местами. На архитектурах cris и s390 первый и второй аргумент переставлены местами.

blackfin, m68k и sparc

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 и более ранние

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

ВЕРСИИ

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

ЗАМЕЧАНИЯ

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

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

ПРИМЕР

Исходный код программы

#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;
    if (argc < 2) {
        fprintf(stderr, "Usage: %s <child-hostname>\n", argv[0]);
        exit(EXIT_SUCCESS);
    }
    /* Выделение стека для потомка */
    stack = malloc(STACK_SIZE);
    if (stack == NULL)
        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);
}