Provided by: manpages-pl-dev_4.25.1-1_all 
NAZWA
clone, __clone2, clone3 - tworzy proces potomny
BIBLIOTEKA
Standardowa biblioteka C (libc, -lc)
SKŁADNIA
/* Prototyp funkcji opakowującej z glibc */
#define _GNU_SOURCE
#include <sched.h>
int clone(int (*fn)(void *_Nullable), void *stack, int flags,
void *_Nullable arg, ... /* pid_t *_Nullable parent_tid,
void *_Nullable tls,
pid_t *_Nullable child_tid */ );
/* Zob. UWAGI dot. prototypu surowego wywołania syst. clone() */
#include <linux/sched.h> /* Definicja struct clone_args */
#include <sched.h> /* Definicja stałych CLONE_* */
#include <sys/syscall.h> /* Definicja stałych SYS_* */
#include <unistd.h>
long syscall(SYS_clone3, struct clone_args *cl_args, size_t size);
Uwaga: glibc nie udostępnia opakowania do clone3(), zatem wymagane jest użycie syscall(2).
OPIS
Niniejsze wywołania systemowe tworzą nowy proces („potomny”), w sposób podobny do fork(2). W przeciwieństwie do fork(2), te wywołania systemowe udostępniają precyzyjniejszą kontrolę wobec kontekstu wykonania, który jest dzielony między procesem wywołującym a procesem potomnym. Przykładowo, za pomocą niniejszych wywołań systemowych, wywołujący może kontrolować czy oba procesy dzielą wirtualną przestrzeń adresową, tablicę deskryptorów pliku i tablicę procedur obsługi sygnałów. Te wywołania systemowego umożliwiają również umieszczenie procesu potomnego w oddzielnych przestrzeniach nazw (zob. namespaces(7)). Proszę zauważyć, że w niniejszym podręczniku systemowym „proces wywołujący” odpowiada zwykle „procesowy macierzystemu”. Proszę jednak sprawdzić opisy CLONE_PARENT i CLONE_THREAD niżej. Niniejsza strona podręcznika opisuje następujące interfejsy: • Funkcję opakowującą clone() z glibc i podległe wywołanie systemowe, w oparciu o które działa. Główna część podręcznika opisuje funkcję opakowującą; różnice w stosunku do surowego wywołania systemowego opisano bliżej końca. • Nowsze wywołanie systemowe clone3(). W pozostałej treści niniejszego podręcznika, pojęcie „wywołanie clone” lub „wywołanie klonowania” używane jest przy opisywaniu szczegółów odnoszących się do wszystkich tych interfejsów. Funkcja opakowująca clone() Gdy proces potomny tworzony jest za pomocą funkcji opakowującej clone(), rozpoczyna on wykonanie od wywołania funkcji, na którą wskazuje argument fn (różni się to od fork(2), gdzie proces potomny kontynuuje wykonanie od miejsca wywołania fork(2)). Argument arg jest przekazywany jako argument do funkcji fn. Gdy funkcja fn(arg) powróci, proces potomny kończy działanie. Liczba całkowita zwrócona przez fn jest statusem zakończenia procesu potomnego. Proces potomny może również zakończyć się jawnie wołając exit(2) lub po otrzymaniu krytycznego sygnału. Argument stack określa położenie stosu używanego przez proces potomny. Ponieważ potomek i proces wywołujący mogą współdzielić pamięć, nie jest możliwe, aby proces potomny korzystał z tego samego stosu, co proces wywołujący. Proces wywołujący musi więc przydzielić obszar pamięci przeznaczony na stos potomka i przekazać wskaźnik do tego obszaru w clone. Stosy rosną w dół na wszystkich procesorach, na których działa Linux (z wyjątkiem procesorów HP PA), więc stack zazwyczaj wskazuje na najwyższy adres obszaru pamięci zarezerwowanego na stos potomka. Proszę zauważyć, że clone() nie zapewnia mechanizmu, w którym wywołujący mógłby poinformować jądro o wielkości obszaru stosu. Pozostałe argumenty clone() opisano poniżej. clone3() Wywołanie systemowe clone3() udostępnia nadzbiór funkcjonalności wobec starszego interfejsu clone(). Zawiera również wiele usprawnień API m.in: przestrzeń na dodatkowe bity znaczników, przejrzystszy podział stosowania różnych argumentów oraz możliwość określenia rozmiaru przestrzeni stosu procesu potomnego. Podobnie jak fork(2), clone3() powraca zarówno w procesie macierzystym, jak i potomnym. Zwraca 0 do procesu potomnego, natomiast procesowi macierzystemu zwraca PID procesu potomnego. Argumentem cl_args clone3() jest struktura w następującej postaci: struct clone_args { u64 flags; /* Maska bitowa znaczników */ u64 pidfd; /* Gdzie przechowywać deskryptor pliku PID (int *) */ u64 child_tid; /* Gdzie przechowywać TID p. potomnego, w pamięci p. potomnego (pid_t *) */ u64 parent_tid; /* Gdzie przechowywać TID, w pamięci procesu macierzystego (pid_t *) */ u64 exit_signal; /* Sygnał do dostarcz. przy zakończeniu procesu potomnego */ u64 stack; /* Wskaźnik do najniższych bajtów stosu */ u64 stack_size; /* Rozmiar stosu */ u64 tls; /* Położenie nowego TLS */ u64 set_tid; /* Wskaźnik do tablicy pid_t (od Linuksa 5.5) */ u64 set_tid_size; /* Liczba elementów w set_tid (od Linuksa 5.5) */ u64 cgroup; /* Deskryptor pliku docelowej gr. kontr. procesu potomnego (od Linuksa 5.7) */ }; Argument size dostarczany do clone3() powinien być zainicjowany z rozmiarem tej struktury (obecność argumentu size pozwala na przyszłe poszerzanie struktury clone_args). Stos procesu potomnego podaje się za pomocą cl_args.stack, które wskazuje na najniższe bajty w przestrzeni stosu oraz za pomocą cl_args.stack_size, które określa rozmiar stosu w bajtach. W przypadku gdy poda się znacznik CLONE_VM (zob. niżej), stos musi być jawnie zaalokowany i określony. W przeciwnym przypadku, te dwa pola można podać jako NULL i 0, co powoduje używanie przez proces potomny tej samej przestrzeni stosu, z jakiej korzysta proces macierzysty (we własnej wirtualnej przestrzeni adresowej procesu potomnego). Pozostałe pola argumentu cl_args opisano niżej. Równoważność pomiędzy argumentami clone() i clone3() W odróżnieniu do starszego interfejsu clone(), którego argumenty są przekazywane pojedynczo, w nowszym interfejsie clone3() argumenty są łączone w strukturze clone_args pokazanej wyżej. Struktura pozwala na przekazanie nadzbioru informacji, przekazywanych za pomocą argumentów clone(). Poniższa tabela ukazuje równoważność pomiędzy argumentami clone() i polami w argumencie clone_args przekazywanym clone3(): clone() clone3() Uwagi pole cl_args flags & ~0xff flags Do większości znaczników; szczegóły niżej parent_tid pidfd Zob. CLONE_PIDFD child_tid child_tid Zob. CLONE_CHILD_SETTID parent_tid parent_tid Zob. CLONE_PARENT_SETTID flags & 0xff exit_signal stack stack --- stack_size tls tls Zob. CLONE_SETTLS --- set_tid Zob. niżej aby poznać szczegóły --- set_tid_size --- cgroup Zob. CLONE_INTO_CGROUP Sygnał zakończenia potomka Gdy proces potomny zostanie zakończony, do rodzica może być wysłany sygnał. Sygnał zakończenia jest określany niższym bajtem flags (clone()) lub cl_args.exit_signal (clone3()). Jeśli określono inny sygnał niż SIGCHLD, to proces macierzysty musi podać opcję __WALL lub __WCLONE czekając na potomka w wait(2). Gdy sygnał nie zostanie określony (tj. podano zero), to proces macierzysty nie zostanie zawiadomiony o zakończeniu pracy potomka. Tablica set_tid Domyślnie, jądro wybiera następny numer PID dla nowego procesu, w każdej przestrzeni nazw PID, w której jest on obecny. Przy tworzeniu procesu za pomocą clone3(), tablicę set_tid (dostępną od Linuksa 5.5) można użyć do wybrania konkretnych PID-ów w niektórych lub we wszystkich przestrzeniach nazw PID, w których jest on obecny. Jeśli PID nowo tworzonego procesu ma być ustawiony tylko w bieżącej przestrzeni nazw PID lub w nowo tworzonej przestrzeni nazw PID (jeśli flags zawiera CLONE_NEWPID), to pierwszym elementem w tablicy set_tid musi być żądany PID, a set_tid_size musi wynosić 1. Jeśli PID nowo tworzonego procesu ma mieć określoną wartość w wielu przestrzeniach nazw PID, to tablica set_tid może zawierać wiele wpisów. Pierwszy wpis definiuje PID najbardziej zagnieżdżonej przestrzeni nazw PID, a każdy kolejny zawiera PID w odpowiadającej przestrzeni nazw PID przodka. Liczba przestrzeni nazw PID, w której PID ma być ustawiony, jest definiowana przez set_tid_size, które nie może być większe od liczby aktualnie zagnieżdżonych przestrzeni nazw. Aby utworzyć proces z następującymi PID-ami w hierarchii przestrzeni nazw PID: Poziom zagn. PID Żądany PID Uwagi 0 31496 Najbardziej zewnętrzna p. n. PID 1 42 2 7 Najbardziej wewnętrzna p. n. PID Należy ustawić tablicę na set_tid[0] = 7; set_tid[1] = 42; set_tid[2] = 31496; set_tid_size = 3; Jeśli mają być określone jedynie PID-y w dwóch najbardziej wewnętrznych przestrzeniach nazw PID, należy ustawić tablicę na: set_tid[0] = 7; set_tid[1] = 42; set_tid_size = 2; PID w przestrzeni nazw PID poza dwoma najbardziej wewnętrznymi przestrzeniami nazw PID jest wybierany w ten sam sposób, jak inne PID-y. Funkcja set_tid wymaga przywileju (ang. capability) CAP_SYS_ADMIN lub (od Linuksa 5.9) CAP_CHECKPOINT_RESTORE we wszystkich posiadanych przestrzeniach nazw użytkownika, w których PID ma być zmieniany. Wywołujący mogą wybrać PID większy od 1 jedynie, gdy w danej przestrzeni nazw PID istnieje już proces init (tj. proces z PID 1). W przeciwnym przypadku, wpis PID dla tej przestrzeni nazw musi wynosić 1. Maska znaczników clone() i clone3() umożliwiają użycie maski bitowej znaczników, które modyfikują ich zachowanie i pozwalają wywołującemu na określenie tego, co ma być dzielone między procesem wywołującym a potomnym. Maska bitowa — argument flags clone() lub pole cl_args.flags przekazywane do clone3() — jest nazywana w pozostałem części niniejszego podręcznika maską flags. Maskę flags można podać jako sumę bitową (OR) zera lub więcej z poniższych zmiennych. Poza wskazanymi wyjątkami, znaczniki te są dostępne (i mają takie samo zastosowanie) w clone() i clone3(). CLONE_CHILD_CLEARTID (od Linuksa 2.5.49) Czyści (zeruje) identyfikator wątku potomnego w położeniu, na które wskazuje child_tid (clone()) lub cl_args.child_tid (clone3()) w pamięci potomka, gdy potomek istnieje i wybudza zatrzask (mutex) pod tym adresem. Adres można zmienić wywołaniem systemowym set_tid_address(2). Używane przez biblioteki związane z wątkami. CLONE_CHILD_SETTID (od Linuksa 2.5.49) Przechowuje identyfikator wątku potomnego w położeniu, na które wskazuje child_tid (clone()) lub cl_args.child_tid (clone3()) w pamięci potomka. Operacja przechowania kończy się przed zwróceniem kontroli przez wywołanie clone do przestrzeni użytkownika w procesie potomnym (proszę zauważyć, że operacja przechowania może nie zakończyć się przed powrotem przez wywołanie clone do procesu macierzystego, co ma znaczenie, jeśli używa się również znacznika CLONE_VM). CLONE_CLEAR_SIGHAND (od Linuksa 5.5) Domyślnie, dyspozycje sygnału w wątku potomnym są takie same jak w wątku macierzystym. Przy podaniu tego znacznika, wszystkie sygnały, które są obsługiwane przez wątek macierzysty (i nie ustawione na SIG_IGN) są resetowane do swych domyślnych dyspozycji (SIG_DFL) w potomku. Podanie tego znacznika razem z CLONE_SIGHAND jest bezsensowne i niedozwolone. CLONE_DETACHED (historyczny) Przez pewien czas (w trakcie serii rozwojowej Linuksa 2.5) istniał znacznik CLONE_DETACHED, który powodował nieotrzymywanie przez rodzica sygnału przy przerwaniu potomka. Ostatecznie, efekt tego znacznika został włączony do znacznika CLONE_THREAD i w momencie wydania Linuksa 2.6.0, znacznik już nie działał. Począwszy od Linuksa 2.6.2, potrzeba podawania tego znacznika razem z CLONE_THREAD zanikła. Znacznik jest wciąż zdefiniowany, lecz z reguły jest ignorowany przy wywoływaniu clone(). Pewne wyjątki opisano przy znaczniku CLONE_PIDFD. CLONE_FILES (od Linuksa 2.0) Jeśli CLONE_FILES będzie ustawione, to proces wywołujący i proces potomny będą współdzielić tablicę deskryptorów plików. Dowolny deskryptor pliku utworzony przez proces wywołujący, jak też przez proces potomny będzie obowiązywać również w drugim procesie. Podobnie, jeśli jeden z procesów zamknie deskryptor pliku lub zmieni stowarzyszone z nim znaczniki (za pomocą operacji F_SETFD fcntl(2)), będzie to obowiązywać również w drugim procesie. Jeśli proces dzielący tablicę deskryptorów pliku wywoła execve(2), to jego tablica deskryptorów pliku zostanie zduplikowana (przestanie być współdzielona). Jeśli CLONE_FILES nie zostanie ustawione, to proces potomny odziedziczy kopię wszystkich deskryptorów plików otwartych w procesie macierzystym w chwili wywołania klonowania. Kolejne operacja otwierające lub zamykające deskryptory pliku przeprowadzone później przez proces wywołujący lub przez proces potomny nie będą miały wpływu na drugi proces. Proszę jednak zauważyć, że zduplikowane deskryptory pliku w potomku odnoszą się tych samym opisów otwartego pliku (ODF) jak odpowiadające im deskryptory pliku w procesie wywołującym; będą zatem dzielić przesunięcie pliku i znaczniki statusu pliku (zob. open(2)). CLONE_FS (od Linuksa 2.0) Jeśli ustawione będzie CLONE_FS, to wywołujący i proces potomny będą współdzielić informacje o systemie plików. Informacje te obejmują katalog główny systemu plików, bieżący katalog roboczy i umaskę. Dowolne z wywołań chroot(2), chdir(2) lub umask(2) wykonane przez proces wywołujący lub proces potomny będzie wpływać również na drugi proces. Jeśli CLONE_FS nie zostanie ustawione, to proces potomny będzie pracować na kopii informacji o systemie plików procesu wywołującego z chwili wywołania klonowania. Wywołania chroot(2), chdir(2) lub umask(2) wykonane później przez jeden z procesów nie będą mieć wpływu na drugi proces. CLONE_INTO_CGROUP (od Linuksa 5.7) Domyślnie, proces potomny jest umieszczany w tej samej grupie kontrolnej (cgroup) w wersji 2, jak rodzic. Znacznik CLONE_INTO_CGROUP pozwala na utworzenie procesu potomnego w innej grupie kontrolnej w wersji 2 (proszę zauważyć, że CLONE_INTO_CGROUP dotyczy tylko grup kontrolnych w wersji 2). Aby umieścić proces potomny w innej grupie kontrolnej, wywołujący określa CLONE_INTO_CGROUP w cl_args.flags i przekazuje deskryptor pliku, który odnosi się do grupy kontrolnej w wersji 2 w polu cl_args.cgroup (ten deskryptor pliku można uzyskać otwierając katalog grupy kontrolnej v2, za pomocą znacznika O_RDONLY lub O_PATH). Proszę zauważyć, że obowiązują wszystkie zwykłe ograniczenia na umieszczanie procesu w grupie kontrolnej w wersji 2 (opisane w cgroups(7)). Pośród możliwych zastosowań CLONE_INTO_CGROUP są następujące: • Utworzenie procesu w grupie kontrolnej innej niż grupa kontrolna rodzica, umożliwia menedżerowi usług bezpośrednie tworzenie nowych usług w oddzielnych grupach kontrolnych. Eliminuje się w ten sposób narzut księgowania, który spowodowany byłby tworzeniem procesu potomnego pierwotnie w tej samej grupie kontrolnej co rodzic, a dopiero później przenoszenie go do docelowej grupy kontrolnej. Co więcej, tworzenie procesu potomnego od razu w docelowej grupie kontrolnej jest zdecydowanie tańsze, niż przenoszenie procesu potomnego do docelowej grupy kontrolnej dopiero po utworzeniu. • Znacznik CLONE_INTO_CGROUP pozwala również na utworzenie zamrożonego procesu potomnego, przez utworzenie go w zamrożonej grupie kontrolnej (zob. cgroups(7) aby dowiedzieć się więcej o kontrolerze freezer). • W przypadku aplikacji korzystających z wątków (lub choćby implementacji wątków korzystających z grup kontrolnych do limitowania poszczególnych wątków), da się ustanowić ustalony schemat grupy kontrolnej, przed utworzeniem każdego wątku bezpośrednio w jego docelowej grupie kontrolnej. CLONE_IO (od Linuksa 2.6.25) Jeśli CLONE_IO jest ustawiony, to nowy proces dzieli kontekst wejścia/wyjścia z procesem wywołującym. Jeśli znacznik nie jest ustawiony, to (jak przy fork(2)) nowy proces posiada swój kontekst wejścia/wyjścia. Kontekst wejścia/wyjścia (we/wy) jest zakresem we/wy planisty dysku (tj. tym, co planista we/wy używa do planowania we/wy procesu). Jeśli procesy dzielą ten sam kontekst we/wy, to są traktowane jako jedność przez planistę we/wy. Muszą zatem dzielić czas dysku. W przypadku pewnych planistów we/wy, jeśli dwa procesy dzielą kontekst we/wy, to pozwala się im na przeplatanie dostępu do dysku. Jeśli wiele wątków korzysta z we/wy w imieniu jakiegoś procesu (np. aio_read(3)), to aby uzyskać lepszą wydajność wejścia/wyjścia, powinny korzystać z CLONE_IO. Jeśli jądra nie skonfigurowano z opcją CONFIG_BLOCK, to ten znacznik nie daje żadnego efektu. CLONE_NEWCGROUP (od Linuksa 4.6) Tworzy proces w nowej przestrzeni nazw cgroup. Jeśli znacznik nie jest ustawiony (jak w przypadku fork(2)), to proces jest tworzony w tej samej przestrzeni nazw cgroup, co proces wywołujący. Więcej informacji o przestrzeniach nazw cgroup znajduje się w podręczniku cgroup_namespaces(7). Jedynie proces uprzywilejowany (CAP_SYS_ADMIN) może użyć CLONE_NEWCGROUP. CLONE_NEWIPC (od Linuksa 2.6.19) Jeśli CLONE_NEWIPC jest ustawiony, to proces jest tworzony w nowej przestrzeni nazw IPC. Jeśli znacznik nie jest ustawiony (jak w przypadku fork(2)), to proces jest tworzony w tej samej przestrzeni nazw IPC, co proces wywołujący. Więcej informacji o przestrzeniach nazw IPC znajduje się w podręczniku ipc_namespaces(7). Jedynie proces uprzywilejowany (CAP_SYS_ADMIN) może użyć CLONE_NEWIPC. Niniejszy znacznik nie może być podany razem z CLONE_SYSVSEM. CLONE_NEWNET (od Linuksa 2.6.24) (Implementacja tej flagi została ukończona dopiero w okolicy Linuksa 2.6.29). Jest CLONE_NEWNET jest ustawiony, to proces jest tworzony w nowej przestrzeni nazw sieci. Jeśli znacznik nie jest ustawiony (jak w przypadku fork(2)), to proces jest tworzony w tej samej przestrzeni nazw sieci, co proces wywołujący. Więcej informacji o przestrzeniach nazw sieci znajduje się w podręczniku network_namespaces(7). Jedynie proces uprzywilejowany (CAP_SYS_ADMIN) może użyć CLONE_NEWNET. CLONE_NEWNS (od Linuksa 2.4.19) Jeśli ustawiono CLONE_NEWNS, sklonowany potomek jest uruchamiany w nowej przestrzeni nazw montowań, inicjowanej jako kopia przestrzeni nazw rodzica. Jeśli nie ustawiono CLONE_NEWNS, to potomek istnieje w tej samej przestrzeni nazw montowań, co rodzic. Więcej informacji o przestrzeniach nazw montowań znajduje się w podręcznikach namespaces(7) i mount_namespaces(7). Znacznik CLONE_NEWNS może zostać użyty jedynie przez proces uprzywilejowany (CAP_SYS_ADMIN). Zabronione jest podanie w tym samym wywołaniu klonowania zarówno CLONE_NEWNS, jak i CLONE_FS. CLONE_NEWPID (od Linuksa 2.6.24) Jest CLONE_NEWPID jest ustawiony, to proces jest tworzony w nowej przestrzeni nazw PID. Jeśli znacznik nie jest ustawiony (jak w przypadku fork(2)), to proces jest tworzony w tej samej przestrzeni nazw PID, co proces wywołujący. Więcej informacji o przestrzeniach nazw PID znajduje się w podręcznikach namespaces(7) i pid_namespaces(7). CLONE_NEWPID może zostać użyty jedynie przez proces uprzywilejowany (CAP_SYS_ADMIN). Nie można podać tego znacznika razem z CLONE_THREAD. CLONE_NEWUSER (Flaga ta nabrała znaczenia dla clone() w Linuksie 2.6.23, bieżąca semantyka clone() pojawiła się w Linuksie 3.5, a ostatnie elementy dające pełną funkcjonalność przestrzeni nazw użytkownika ukończono w Linuksie 3.8). Jest CLONE_NEWUSER jest ustawiony, to proces jest tworzony w nowej przestrzeni nazw użytkownika. Jeśli znacznik nie jest ustawiony (jak w przypadku fork(2)), to proces jest tworzony w tej samej przestrzeni nazw użytkownika, co proces wywołujący. Więcej informacji o przestrzeniach nazw użytkownika znajduje się w podręcznikach namespaces(7) i user_namespaces(7). Przed Linuksem 3.8, użycie CLONE_NEWUSER wymagało posiadania trzech przywilejów (ang. capabilities) przez wywołującego: CAP_SYS_ADMIN, CAP_SETUID i CAP_SETGID. Od Linuksa 3.8, do utworzenia przestrzeni nazw użytkownika nie są wymagane przywileje. Znacznika tego nie można podać razem z CLONE_THREAD lub CLONE_PARENT. Ze względów bezpieczeństwa, CLONE_NEWUSER nie można podać razem z CLONE_FS. CLONE_NEWUTS (od Linuksa 2.6.19) Jest CLONE_NEWUTS jest ustawiony, to proces jest tworzony w nowej przestrzeni nazw UTS, której identyfikatory są inicjowane przez zduplikowanie identyfikatorów z przestrzeni nazw UTS procesu wywołującego. Jeśli znacznik nie jest ustawiony (jak w przypadku fork(2)), to proces jest tworzony w tej samej przestrzeni nazw UTS, co proces wywołujący. Więcej informacji o przestrzeniach nazw UTS znajduje się w podręczniku uts_namespaces(7). Jedynie proces uprzywilejowany (CAP_SYS_ADMIN) może użyć CLONE_NEWUTS. CLONE_PARENT (od Linuksa 2.3.12) Jeśli CLONE_PARENT będzie ustawione, to rodzic nowego procesu potomnego (zwrócony przez getppid(2)) będzie ten sam, co dla procesu wywołującego. Jeśli CLONE_PARENT nie zostanie ustawione, to (jak dla fork(2)) rodzicem potomka będzie proces wywołujący. Należy zauważyć, że to proces macierzysty, zwracany przez getppid(2), zostanie powiadomiony o zakończeniu pracy przez potomka, więc jeśli CLONE_PARENT będzie ustawione, to zawiadomiony zostanie rodzic procesu wywołującego, a nie sam proces wywołujący. Znacznika CLONE_PARENT nie można użyć w wywołaniach klonowania przez globalny proces init (o PID 1 w pierwotnej przestrzeni nazw PID) oraz procesy init w innych przestrzeniach nazw PID. To ograniczenie zapobiega tworzeniu zakorzenionych w wielu miejscach drzew procesów oraz tworzeniu zombie w pierwotnej przestrzeni nazw, których nie da się dorżnąć (unreapable). CLONE_PARENT_SETTID (od Linuksa 2.5.49) Przechowuje identyfikator wątku potomka w położeniu, na które wskazuje parent_tid (clone()) lub cl_args.parent_tid (clone3()) w pamięci rodzica (w Linuksie 2.5.32-2.5.48 istniał znacznik CLONE_SETTID, który działał w ten sam sposób). Operacja przechowania kończy się, przed zwróceniem kontroli do przestrzeni użytkownika przez wywołanie klonowania. CLONE_PID (od Linuksa 2.0 do Linuksa 2.5.15) Jeśli CLONE_PID jest ustawiony, to proces potomny jest tworzony z tym samym identyfikatorem jak proces wywołujący. Trudno wymyślić jego przydatne zastosowanie, poza hakowaniem systemu. Od Linuksa 2.3.21, ten znacznik mógł być podany tylko przez systemowy proces rozruchu (PID 0). Znacznik zupełnie zniknął ze źródeł jądra w Linuksie 2.5.16. Następnie jądro po cichu ignorowało ten bit, gdy był podany w masce flags. Znacznie później, ten sam bit użyto do znacznika CLONE_PIDFD. CLONE_PIDFD (od Linuksa 5.2) Jeśli znacznik jest podany, to deskryptor pliku PID odnoszącego się do procesu potomnego jest alokowany i umieszczany w określonym położeniu pamięci rodzica. Na tym nowym deskryptorze pliku ustawiany jest znacznik zamknij-przy-wykonaniu. Deskryptory pliku PID można wykorzystać w celach opisanych w podręczniku pidfd_open(2). • Jeśli korzysta się z clone3(), to deskryptor pliku PID jest umieszczany w położeniu, na które wskazuje cl_args.pidfd. • Jeśli korzysta się z clone(), to deskryptor pliku PID jest umieszczany w położeniu, na które wskazuje parent_tid. Ponieważ argument parent_tid jest używany do zwrócenia deskryptora pliku PID, nie można użyć CLONE_PIDFD razem z CLONE_PARENT_SETTID przy wywoływaniu clone(). Nie da się obecnie korzystać z tego znacznika razem z CLONE_THREAD. Oznacza to, że proces identyfikowany przez deskryptor pliku PID będzie zawsze liderem grupy wątków. Jeśli przestarzały znacznik CLONE_DETACHED poda się razem z CLONE_PIDFD przy wywoływaniu clone(), to zwracany jest błąd. Błąd występuje również jeśli poda się CLONE_DETACHED przy wywoływaniu clone3(). Zwracanie błędu zapewnia, że bit odnoszący się do CLONE_DETACHED może być w przyszłości użyty ponownie do następnych funkcji deskryptora pliku PID. CLONE_PTRACE (od Linuksa 2.2) Jeśli zostanie podane CLONE_PTRACE, a proces wywołujący będzie śledzony, to śledzenie obejmie również potomka (zobacz ptrace(2)). CLONE_SETTLS (od Linuksa 2.5.32) Deskryptor TLS (Thread Local Storage — pamięć lokalna wątku) jest ustawiony na tls. Interpretacja tls i jego skutek zależy od architektury. Na x86, tls jest interpretowane jako struct user_desc * (zob. set_thread_area(2)). Na x86-64 jest to nowa wartość, jaka ma być ustawiona w bazowym rejestrze %fs (zob. argument ARCH_SET_FS do arch_prctl(2)). Na architekturach ze specjalnym rejestrem TLS, jest to nowa wartość tego rejestru. Znacznik ten wymaga szczegółowej wiedzy i zwykle nie powinno się go używać poza bibliotekami implementującymi wątkowanie. CLONE_SIGHAND (od Linuksa 2.0) Jeśli CLONE_SIGHAND będzie ustawione, to proces wywołujący i procesy potomne będą współdzielić tablicę programów obsługi sygnałów. Jeśli proces wywołujący lub proces potomny wywoła sigaction(2), aby zmienić zachowanie towarzyszące sygnałowi, zachowanie to zostanie zmienione również w drugim procesie. Jednakże, proces wywołujący i proces potomny wciąż będą posiadać osobne maski sygnałów i zestawy sygnałów oczekujących. Zatem jeden z nich może zablokować lub odblokować niektóre sygnały za pomocą sigprocmask(2) nie wpływając na drugi proces. Jeśli CLONE_SIGHAND nie zostanie ustawione, to proces potomny odziedziczy kopię programów obsługi sygnałów od procesu wywołującego z chwili wywołania klonowania. Wywołania sigaction(2) przeprowadzone później przez jeden z procesów nie będą mieć wpływu na drugi proces. Od Linuksa 2.6.0, maska flags musi również zawierać CLONE_VM, jeśli podano CLONE_SIGHAND. CLONE_STOPPED (od Linuksa 2.6.0) Jeśli CLONE_STOPPED jest ustawione, to potomek jest początkowo zatrzymany (jakby otrzymał sygnał SIGSTOP) i musi być wznowiony sygnałem SIGCONT. Znacznik był oznaczony jako przestarzały od Linuksa 2.6.25 i został zupełnie usunięty w Linuksie 2.6.38. Od tego czasu jądro po cichu ignoruje go, nie wypisując błędu. Od Linuksa 4.6, ten sam bit służy znacznikowi CLONE_NEWCGROUP. CLONE_SYSVSEM (od Linuksa 2.5.10) Jeśli ustawiony jest CLONE_SYSVSEM to potomek i proces wywołujący dzielą jedną listę wartości dostosowań semaforów Systemu V (semadj; zob. semop(2)). W tym przypadku wspólna lista zbiera wartości semadj ze wszystkich procesów dzielących listę, a dostosowania semaforów są wykonywane tylko gdy ostatni proces dzielący listę zostanie zakończony (lub przestanie dzielić listę, za pomocą unshare(2)). Jeśli znacznik ten nie jest ustawiony, to potomek posiada oddzielną listę semadj, która początkowo jest pusta. CLONE_THREAD (od Linuksa 2.4.0) Jeśli ustawiony jest CLONE_THREAD to potomek jest umieszczany w tej samej grupie wątków, co proces wywołujący. Aby dalsza część opisu CLONE_THREAD była bardziej przejrzysta, termin „wątek” oznaczać będzie tu procesy w grupie wątków. Grupy wątków zostały dodane w Linuksie 2.4 do obsługi wątków POSIX dla zbioru procesów współdzielących ten sam PID. Wewnętrznie, ten wspólny PID jest tzw. identyfikatorem grupy wątków (ang. thread group ID — TGID) dla grupy wątków. Od Linuksa 2.4 wywołania getpid(2) zwracają TGID wywołującego. Wątki wewnątrz grupy można rozróżnić za pomocą ich unikatowego (w systemie) identyfikatora wątku (ang. thread ID — TID). TID nowego wątku jest dostępny jako wynik funkcji zwracany do wywołującego, a sam wątek może uzyskać swój TID za pomocą gettid(2). Gdy wywołanie clone ma miejsce bez podania CLONE_THREAD, to wynikowy wątek jest umieszczany w nowej grupie wątków, której TGID jest taki sam jak TID wątku. Wątek ten staje się liderem nowej grupy wątków. Nowy wątek utworzony przy podaniu CLONE_THREAD ma ten sam proces macierzysty jak proces, który wykonał wywołanie klonowania (tj. jak CLONE_PARENT), tak więc wywołanie getppid(2) zwróci tę samą wartość dla wszystkich wątków w grupie wątków. Gdy wątek z CLONE_THREAD zostanie zakończony, wątek który go utworzył nie otrzymuje sygnału SIGCHLD (ani innego sygnału przerwania); statusu takiego wątku nie da się również pozyskać za pomocą wait(2) (taki wątek jest nazywany oddzielonym — ang. detached). Po tym, jak wszystkie wątki w grupie wątków zakończą się, proces macierzysty grupy wątków otrzymuje sygnał SIGCHLD (lub inny sygnał przerwania). Jeśli któryś z wątków w grupie wątków wykona execve(2), to wszystkie wątki poza liderem grupy wątków są zakańczane i nowy program wykonywany jest przez lidera grupy wątków. Jeśli jeden z wątków w grupie wątków tworzy potomka za pomocą fork(2), to każdy wątek w grupie może czekać (wait(2)) na tego potomka. Od Linuksa 2.5.35, maska flags musi zawierać również CLONE_SIGHAND jeśli podano CLONE_THREAD (i proszę zauważyć, że od Linuksa 2.6.0, CLONE_SIGHAND wymaga również zamieszczenia CLONE_VM). Akcje i dyspozycje sygnałów mają znaczenie dla całego procesu: jeśli do wątku dostarczony zostanie nieobsłużony sygnał, to dotknie on (przerwie, zatrzyma, wznowi, ustawi ignorowanie) wszystkich członków grupy wątków. Każdy wątek ma swoją maskę sygnałów, jak ustawianą przez sigprocmask(2). Sygnał może być kierowany do procesu lub kierowany do wątku. Sygnał kierowany do procesu jest przeznaczony do grupy wątku (tj. TGID) i jest dostarczany do dowolnie wybranego wątku spośród tych, które nie blokują sygnału. Sygnał może być kierowany do procesu, ponieważ został wygenerowany przez jądro z powodów innych niż wyjątek sprzętowy, albo ponieważ został wysłany za pomocą kill(2) lub sigqueue(3). Sygnał kierowany do wątku jest przeznaczony (tj. dostarczany) do określonego wątku. Sygnał może być kierowany do wątku, ponieważ został wysłany za pomocą tgkill(2) lub pthread_sigqueue(3), albo ponieważ wątek wykonał instrukcję języka maszynowego, która wyzwoliła wyjątek sprzętowy (np. nieprawidłowy dostęp do pamięci wyzwalający SIGSEGV lub wyjątek zmiennoprzecinkowy wyzwalający SIGFPE). Wywołanie do sigpending(2) zwraca sygnał, który jest ustawiany na sumę oczekującego sygnału skierowanego do procesu oraz sygnałów które są oczekujące dla wątku wywołującego. Jeśli sygnał kierowany do procesu zostanie dostarczony do grupy wątków, a grupa ta ma zainstalowaną procedurę obsługi sygnału, to jest ona wywoływana w dokładnie jednym, dowolnie wybranym członku grupy wątków, który nie zablokował sygnału. Jeśli na zaakceptowanie tego samego sygnału za pomocą sigwaitinfo(2) czeka wiele wątków w grupie, to jądro wybierze w sposób dowolny jeden z wątków, który otrzyma sygnał. CLONE_UNTRACED (od Linuksa 2.5.46) Jeśli podano CLONE_UNTRACED, to proces śledzący nie może wymusić CLONE_PTRACE na tym procesie potomnym. CLONE_VFORK (od Linuksa 2.2) Jeśli CLONE_VFORK będzie ustawione, wykonywanie procesu wywołującego zostanie wstrzymane do chwili, gdy potomek zwolni swoją pamięć wirtualną za pomocą execve(2) lub _exit(2) (jak w przypadku vfork(2)). Jeśli CLONE_VFORK nie zostanie ustawione, wtedy zarówno proces wywołujący, jak i potomny podlegają po wywołaniu clone szeregowaniu zadań i aplikacja nie może zakładać, że ich wykonywanie będzie się odbywać w określonej kolejności. CLONE_VM (od Linuksa 2.0) Jeśli CLONE_VM będzie ustawione, to proces wywołujący i potomny będą działać w tym samym obszarze pamięci. W szczególności, zapisy do pamięci wykonywane przez proces wywołujący lub przez proces potomny będą widoczne dla drugiego z procesów. Ponadto, dowolne mapowania pamięci i usunięcia mapowań wykonane przez jeden z tych procesów za pomocą mmap(2) lub munmap(2) będą dotyczyć również drugiego procesu. Jeśli CLONE_VM nie zostanie ustawione, to proces potomny będzie działać w kopii obszaru pamięci procesu wywołującego, wykonanej w chwili wywołania klonowania. Zapisy do pamięci oraz mapowania i usunięcia mapowań wykonane przez jeden z tych procesów nie będą dotyczyć drugiego z nich, tak jak w przypadku fork(2). Jeśli podano znacznik CLONE_VM, a nie podano znacznika CLONE_VFORK to wszystkie alternatywne stosy sygnałów ustanowione przez sigaltstack(2) są czyszczone w procesie potomnym.
WARTOŚĆ ZWRACANA
Po pomyślnym zakończeniu, w wątku rodzica zwracany jest identyfikator wątku potomka. W wypadku błędu, w
kontekście procesu wywołującego zwracane jest -1, a proces potomny nie jest tworzony i ustawiane jest
errno wskazując błąd.
BŁĘDY
EACCES (tylko clone3())
W cl_args.flags podano CLONE_INTO_CGROUP, nie spełniono ograniczeń (opisanych w cgroups(7)), w
odniesieniu do cl_args.cgroup, dotyczących umieszczania procesu potomnego w grupie kontrolnej w
wersji 2.
EAGAIN Działa już zbyt wiele procesów; zob. fork(2).
EBUSY (tylko clone3())
W cl_args.flags podano CLONE_INTO_CGROUP, lecz deskryptor pliku podany w cl_args.cgroup odnosi się
do grupy kontrolnej w wersji 2, w której włączony jest kontroler domeny.
EEXIST (tylko clone3())
Jeden (lub więcej) PID podany w set_tid już istnieje w odpowiedniej przestrzeni nazw PID.
EINVAL W masce flags podano jednocześnie CLONE_SIGHAND i CLONE_CLEAR_SIGHAND.
EINVAL W masce flags podano CLONE_SIGHAND, lecz nie podano CLONE_VM (od Linuksa 2.6.0).
EINVAL W masce flags podano CLONE_THREAD, lecz nie podano CLONE_SIGHAND (od Linuksa 2.5.35).
EINVAL W masce flags podano CLONE_THREAD, lecz bieżący proces użył uprzednio unshare(2) ze znacznikiem
CLONE_NEWPID lub użył setns(2) do ponownego związania się z przestrzenią nazw PID.
EINVAL W masce flags podano jednocześnie CLONE_FS i CLONE_NEWNS.
EINVAL (od Linuksa 3.9)
W masce flags podano jednocześnie CLONE_NEWUSER i CLONE_FS.
EINVAL W masce flags podano jednocześnie CLONE_NEWIPC i CLONE_SYSVSEM.
EINVAL W masce flags podano jednocześnie CLONE_FS i CLONE_NEWNS.
EINVAL W masce flags podano jednocześnie CLONE_FS i CLONE_NEWNS.
EINVAL (od Linuksa 2.6.32)
Podano CLONE_PARENT, a wywołujący jest procesem init.
EINVAL Zwracane przez funkcję opakowującą clone() z glibc, gdy fn lub stack określono jako NULL.
EINVAL W masce flags podano CLONE_NEWIPC, lecz jądro nie zostało skonfigurowane z opcjami CONFIG_SYSVIPC
i CONFIG_IPC_NS.
EINVAL W masce flags podano CLONE_NEWNET, lecz jądro nie zostało skonfigurowane z opcją CONFIG_NET_NS.
EINVAL W masce flags podano CLONE_NEWPID, lecz jądro nie zostało skonfigurowane z opcją CONFIG_PID_NS.
EINVAL W masce flags podano CLONE_NEWUSER, lecz jądro nie zostało skonfigurowane z opcją CONFIG_USER_NS.
EINVAL W masce flags podano CLONE_NEWUTS, lecz jądro nie zostało skonfigurowane z opcją CONFIG_UTS_NS.
EINVAL Stos stack nie jest wyrównany do odpowiedniej granicy na tej architekturze. Przykładowo na
aarch64, stack musi być wielokrotnością 16.
EINVAL (tylko clone3())
W masce flags podano CLONE_DETACHED.
EINVAL (tylko clone())
W masce flags podano CLONE_PIDFD jednocześnie z CLONE_DETACHED.
EINVAL W masce flags podano CLONE_PIDFD jednocześnie z CLONE_THREAD.
EINVAL (tylko clone())
W masce flags podano CLONE_PIDFD jednocześnie z CLONE_PARENT_SETTID.
EINVAL (tylko clone3())
set_tid_size jest większy od liczby zagnieżdżonych przestrzeni nazw PID.
EINVAL (tylko clone3())
Jeden z PID-ów podanych w set_tid był nieprawidłowy.
EINVAL (tylko clone3())
W masce flags podano CLONE_THREAD lub CLONE_PARENT, lecz w exit_signal określono sygnał.
EINVAL (tylko AArch64, Linux 4.6 i wcześniejsze)
stack nie był wyrównany do granicy 128-bitów.
ENOMEM Za mało pamięci aby przydzielić strukturę zadania dla procesu potomnego, lub aby skopiować
niezbędne fragmenty kontekstu procesu wywołującego.
ENOSPC (od Linuksa 3.7)
W masce flags podano CLONE_NEWPID, lecz zostałby przekroczony limit zagnieżdżenia przestrzeni nazw
PID; zob. pid_namespaces(7).
ENOSPC (od Linuksa 4.9; wcześniej EUSERS)
W masce flags podano CLONE_NEWUSER, a wywołanie przekroczyłoby limit liczby zagnieżdżonych
przestrzeni nazw użytkownika. Zob. user_namespaces(7).
Od Linuksa 3.11 do Linuksa 4.8, diagnozowanym w tym przypadku błędem był EUSERS.
ENOSPC (od Linuksa 4.9)
Jedna z wartości w masce flags określiła utworzenie nowej przestrzeni nazw użytkownika, lecz
uczynienie tego, spowodowałoby przekroczenie limitu zdefiniowanego przez odpowiedni plik w
/proc/sys/user. Więcej informacji znajduje się w podręczniku namespaces(7).
EOPNOTSUPP (tylko clone3())
W cl_args.flags podano CLONE_INTO_CGROUP, lecz deskryptor pliku podany w cl_args.cgroup odnosi się
do grupy kontrolnej w wersji 2, która jest w stanie domain invalid.
EPERM CLONE_NEWCGROUP, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID lub CLONE_NEWUTS były
określone przez proces nieuprzywilejowany (proces bez przywileju CAP_SYS_ADMIN).
EPERM CLONE_PID został podany przez proces inny niż proces 0 (błąd ten występował jedynie do Linuksa
2.5.15).
EPERM W masce flags podano CLONE_NEWUSER, lecz ani efektywny identyfikator użytkownika, ani efektywny
identyfikator grupy wywołującego nie jest przypisany do przestrzeni nazw rodzica (zob.
user_namespaces(7)).
EPERM (od Linuksa 3.9)
W masce flags podano CLONE_NEWUSER, a wywołujący znajduje się w środowisku chroot (tj. główny
katalog wywołującego nie jest głównym katalogiem przestrzeni nazw montowań, w której rezyduje).
EPERM (tylko clone3())
set_tid_size był większy niż zero, a wywołujący nie ma przywileju CAP_SYS_ADMIN w jednej lub
większej liczbie przestrzeni nazw użytkownika, które posiadają odpowiednie przestrzenie nazw PID.
ERESTARTNOINTR (od Linuksa 2.6.17)
Wywołanie systemowe przerwano sygnałem i zostanie ono przeładowane (widać to tylko przy
śledzeniu).
EUSERS (od Linuksa 3.11 do Linuksa 4.8)
W masce flags podano CLONE_NEWUSER, a przekroczono by limit liczby zagnieżdżonych przestrzeni nazw
użytkownika. Zob. opis błędu ENOSPC powyżej.
WERSJE
Funkcja opakowująca clone() z biblioteki glibc czyni pewne zmiany w pamięci, na którą wskazuje stack
(zmiany wymagane do prawidłowego ustawienia stosu w stosunku do potomka) przed przywołaniem wywołania
systemowego clone(). Dlatego, w przypadkach gdy clone() służy do rekurencyjnego tworzenia potomków, nie
należy używać bufora w stosie rodzica, jako stosu potomka.
Na i386, nie należy wywoływać clone() za pomocą vsyscall; powinno się to robić bezpośrednio, poprzez int
$0x80.
Różnice biblioteki C/jądra
Surowe wywołanie systemowe clone() jest bliższe fork(2) w tym zakresie, że wykonanie procesu potomnego
jest kontynuowane od miejsca wywołania. Dlatego argumenty fn i arg funkcji opakowującej clone() są
pominięte.
W odróżnienie od opakowania z glibc, surowe wywołanie systemowe clone() jako argument stack akceptuje
NULL (a clone3() podobnie pozwala, aby cl_args.stack wynosiło NULL). W takim przypadku, potomek używa
duplikatu stosu rodzica (jest to dokonywane za pomocą kopiowania-przy-zapisie, co zapewnia, że potomek
otrzyma odrębne kopie stron stosu, gdy jeden z procesów zmodyfikuje stos). W tym przypadku, aby zapewnić
poprawne działanie, nie powinno się podawać opcji CLONE_VM (jeśli potomek współdzieli pamięć z rodzicem
ze względu na znacznik CLONE_VM, to nie zachodzi duplikacja z kopiowaniem-przy-zapisie, co prawdopodobnie
doprowadzi do chaotycznych rezultatów).
Kolejność argumentów również różni się w surowym wywołaniu systemowym, występuje także zmienność
argumentów w zależności od architektury, zgodnie z poniższym opisem.
Interfejsem surowego wywołania systemowego na x86-64 i niektórych innych architekturach (w tym sh, tile i
alpha) jest:
long clone(unsigned long flags, void *stack,
int *parent_tid, int *child_tid,
unsigned long tls);
Na x86-32 i wielu innych popularnych architekturach (w tym score, ARM, ARM 64, PA-RISC, arc, Power PC,
xtensa i MIPS), kolejność dwóch ostatnich argumentów jest zamieniona:
long clone(unsigned long flags, void *stack,
int *parent_tid, unsigned long tls,
int *child_tid);
Na architekturach cris i s390, kolejność pierwszych dwóch argumentów jest zamieniona:
long clone(void *stack, unsigned long flags,
int *parent_tid, int *child_tid,
unsigned long tls);
Na architekturze microblaze występuje dodatkowy argument:
long clone(unsigned long flags, void *stack,
int stack_size, /* Rozmiar stosu */
int *parent_tid, int *child_tid,
unsigned long tls);
blackfin, m68k i sparc
Konwencje przekazywania argumentów na blackfin, m68k i sparc są odmienne od powyższych opisów. Więcej
szczegółów w źródle jądra (i glibc).
ia64
Na ia64 używany jest inny interfejs:
int __clone2(int (*fn)(void *),
void *stack_base, size_t stack_size,
int flags, void *arg, ...
/* pid_t *parent_tid, struct user_desc *tls,
pid_t *child_tid */ );
Powyższy prototyp jest do funkcji opakowującej z glibc; jeśli chodzi o samo wywołanie systemowe, jego
prototyp może być opisany w sposób następujący (jest identyczny do prototypu clone() na microblaze):
long clone2(unsigned long flags, void *stack_base,
int stack_size, /* Rozmiar stosu */
int *parent_tid, int *child_tid,
unsigned long tls);
__clone2() działa w ten sam sposób co clone() z tym wyjątkiem, że stack_base wskazuje na najniższy adres
przestrzeni stosu potomka, a stack_size określa rozmiar stosu, na który wskazuje stack_base.
STANDARDY
Linux.
HISTORIA
clone3()
Linux 5.3.
Linux 2.4 i wcześniejsze
W serii Linuksa 2.4.x, CLONE_THREAD zwykle nie czyniło rodzicem nowego wątku rodzica procesu
wywołującego. Jednak od Linuksa 2.4.7 do Linuksa 2.4.18 znacznik CLONE_THREAD implikował znacznik
CLONE_PARENT (jak ma to miejsce od Linuksa 2.6.0).
W Linuksie 2.4 i wcześniejszych clone() nie przyjmowało argumentów parent_tid, tls ani child_tid.
UWAGI
Jednym z zastosowań tych wywołań systemowych jest implementacja wątków: zarządzanie wieloma przepływami
kontroli w programie, które działają równolegle we współdzielonej przestrzeni adresowej.
Wywołanie systemowe kcmp(2) może posłużyć do sprawdzenia, czy dwa procesy współdzielą różne zasoby, takie
jak tablica deskryptorów pliku, operacje cofnięć semaforów Systemu V lub wirtualną przestrzeń adresową.
Uchwyty zarejestrowane przy pomocy pthread_atfork(3) nie są wykonywane przy wywołaniu klonowania.
USTERKI
Biblioteka GNU C w wersjach od 2.3.4 do 2.24 włącznie, zawierała funkcję opakowującą getpid(2), która przeprowadzała buforowanie PID-ów. To buforowanie zależało od obsługi opakowania clone() z glibc, jednak ograniczenia w implementacji powodowały, że w niektórych przypadkach bufor ten nie był aktualny. W szczególności, jeśli do potomka dostarczano sygnał od razu po wywołaniu clone(), to wywołanie getpid(2) w procedurze obsługi sygnału mogło zwrócić PID procesu wywołującego („rodzica”), jeśli opakowanie clone nie miało jeszcze szansy zaktualizowania bufora PID w potomku (ten opis ignoruje sytuację, gdy potomka utworzono za pomocą CLONE_THREAD; wówczas getpid(2) powinno zwracać tę samą wartość w potomku jak w procesie wywołującym clone(), ponieważ wywołujący i potomek znajdują się w tej samej grupie wątków. Problem nieaktualnego bufora nie występuje również, gdy argument flags zawiera CLONE_VM). Do dotarcia do prawdziwego PID, trzeba było czasem użyć kodu takiego jak poniższy: #include <syscall.h> pid_t mypid; mypid = syscall(SYS_getpid); Ze względu na kłopot z nieaktualnym buforem i inne problemy opisane w getpid(2), funkcjonalność buforowania PID-ów usunięto w glibc 2.25.
PRZYKŁADY
Poniższy program demonstruje użycie clone() do utworzenia procesu potomnego, który wykonuje się w
oddzielnej przestrzeni nazw UTS. Potomek zmienia nazwę stacji w swojej przestrzeni nazw UTS. Rodzic i
potomek wyświetlają następnie systemową nazwę stacji, przez co widać, że różni się ona w przestrzeniach
nazw UTS rodzica i potomka. Przykład użycia tego programu znajduje się w podręczniku setns(2).
W programie przykładowym pamięć, która ma być użyta do stosu potomka, przydzielamy za pomocą mmap(2),
zamiast malloc(3), z następujących powodów:
• mmap(2) przydziela blok pamięci zaczynający się na granicy strony i będący wielokrotnością rozmiaru
strony. Przydaje się to, gdy chcemy ustawić ochronę strony (stronę z ochroną PROT_NONE) na końcu
stosu, za pomocą mprotect(2).
• Możemy podać znacznik MAP_STACK, aby zażądać mapowania, które jest odpowiednie do stosu. W tej chwili
znacznik ten nie daje efektu na Linuksie, ale istnieje i działa na niektórych innych systemach,
dlatego należy go podać ze względu na przenośność.
Kod źródłowy programu
#define _GNU_SOURCE
#include <err.h>
#include <sched.h>
#include <signal.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/utsname.h>
#include <sys/wait.h>
#include <unistd.h>
static int /* Początek funkcje klonowanego potomka */
childFunc(void *arg)
{
struct utsname uts;
/* Zmiana nazwy stacji w przestrzeni nazw UTS potomka. */
if (sethostname(arg, strlen(arg)) == -1)
err(EXIT_FAILURE, "sethostname");
/* Pobranie i wyświetlenie nazwy stacji. */
if (uname(&uts) == -1)
err(EXIT_FAILURE, "uname");
printf("uts.nodename u potomka: %s\n", uts.nodename);
/* Utrzymuje przestrzeń nazw otwartą przez chwilę, śpiąc.
Daje to pole do eksperymentów - do przestrzeni nazw
może np. dołączyć inny proces. */
sleep(200);
return 0; /* Potomek ulega zakończeniu */
}
#define STACK_SIZE (1024 * 1024) /* Rozmiar stosu klon. potomka */
int
main(int argc, char *argv[])
{
char *stack; /* Początek bufora stosu */
char *stackTop; /* Koniec bufora stosu */
pid_t pid;
struct utsname uts;
if (argc < 2) {
fprintf(stderr, "Użycie: %s <child-hostname>\n", argv[0]);
exit(EXIT_SUCCESS);
}
/* Przydzielenie pamięci na stos potomka. */
stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);
if (stack == MAP_FAILED)
err(EXIT_FAILURE, "mmap");
stackTop = stack + STACK_SIZE; /* Założenie: stos rośnie w dół */
/* Utworzenie potomka z własną przestrzenią nazw UTS;
potomek rozpoczyna wykonanie w childFunc(). */
pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
if (pid == -1)
err(EXIT_FAILURE, "clone");
printf("clone() zwróciło %jd\n", (intmax_t) pid);
/* Rodzic przechodzi tutaj */
sleep(1); /* Czas na zmianę nazwy stacji przez potomka */
/* Wyświetla nazwę stacji w przestrzeni nazw UTS rodzica. Będzie
inna, od nazwy stacji w przestrzeni nazw UTS potomka. */
if (uname(&uts) == -1)
err(EXIT_FAILURE, "uname");
printf("uts.nodename u rodzica: %s\n", uts.nodename);
if (waitpid(pid, NULL, 0) == -1) /* Czekanie na potomka */
err(EXIT_FAILURE, "waitpid");
printf("potomek zakończył działanie\n");
exit(EXIT_SUCCESS);
}
ZOBACZ TAKŻE
fork(2), futex(2), getpid(2), gettid(2), kcmp(2), mmap(2), pidfd_open(2), set_thread_area(2), set_tid_address(2), setns(2), tkill(2), unshare(2), wait(2), capabilities(7), namespaces(7), pthreads(7)
TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Przemek Borys <pborys@dione.ids.pl>, Andrzej Krzysztofowicz <ankry@green.mf.pg.gda.pl> i Michał Kułach <michal.kulach@gmail.com> Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI. Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej ⟨manpages-pl- list@lists.sourceforge.net⟩.