Jaderné noviny - 1. 4. 2015: Připojení souborových deskriptorů k procesům pomocí CLONE_FD

12. 7. 2015 | Redakce | Jaderné noviny | 1965×

Stav vydání jádra. Citáty týdne. Připojení souborových deskriptorů k procesům pomocí CLONE_FD.

Stav vydání jádra

Aktuální vývojové jádro je 4.0-rc6, vydané 29. března. Podle Linuse se: "to pomalu uklidňuje, opravy přicházejí ze všech stran. Opravili jsme regresi výkonu NUMA a všeobecně to vypadá dobře. Měli jsme jisté problémy s i915 a dvouchybou u KVM, takže jsem si na chvíli myslel, že půjde o vydání, které si vyžádá rc8, ale možná to nebude nutné."

Stabilní aktualizace: 3.19.3 byla vydána 26. března; verze 3.14.37 a 3.10.73 následovaly den poté.

Citáty týdne

Tento patchset navrhuje řešení. Podpora pro negativní počet procesorů umožňuje škálovat až k O(-NR_CPUS). Čím více máte procesorů tím výše škálujete, až k bodu, kdy software ukončí akci dříve, než ho napíšete (za předpokladu, že máte okolo -1024 CPU). Programování je ještě jednodušší, protože se nemusíte zabývat tolika procesory.

Mějte na paměti, že tento patchset je zatím jen návrh. Žádné sestavení nebylo testováno a ještě nemám potřebný hardware.

-Frederic Weisbecker

32bitový kód je starý, plný otravných háčků, neustále padá, když pracujeme na nových funkcích pro 64 bit. A upřímně, nikoho už 32 bit nezajímá. Pokud vás ano, děláte chybu a měli byste jít s dobou. Běžte ven, zhluboka se nadechněte a projděte se. Jako první věc po návratu se *podívejte* *do* *kalendáře*. Je čas se říct starému 32bitovému písku pápá. Kupte si 64bitový procesor. Žijte trochu. Staňte se součástí skutečného světa.

-Borislav Petkov

Připojení souborových deskriptorů k procesům pomocí CLONE_FD

Tradiční Unixový systém má mnoho výhod, ale šetrnost ke kódu knihoven nebývá jednou z nich. Jádrem problému je použití globálních struktur a mechanismů, se kterými nelze pracovat nezávisle za pomoci aplikaci nebo jakékoli knihovny, kterou by mohly používat; tabulka souborových deskriptorů a vektory pro manipulaci se signály představují jen dva příklady. Nedávno zveřejněný patch se snaží řešit část tohoto problému, ale mohl by vést k větší, dlouhodobější změně, kterak řídit procesy v Linuxu.

Vezměme si například knihovnu, která podřebuje vytvořit podřízený proces pomocí fork() a dostat upozornění, jakmile proces existuje. Knihovna nemůže volat wait(), aniž by blokovala celý proces volání a zasahovat do podřízených procesů, vytvořených jinde v žádosti. Příjem asynchronních oznámení pomocí SIGCHILD má podobný problém: K dispozici je pouze jeden popisovač SIGCHILD, takže jeho zachycení v knihovně se střetává s použitím signálu aplikací. Potřeba zabránit podobným konfliktům kódem aplikace může výrazně omezit možnosti knihovny.

Patch CLONE_FD Joshe Tripletta se pokouší tento konkrétní problém řešit. Přidává novou vlajku, CLONE_FD, k variantě clone_() systémového volání (clone4()); Je-li vlajka přítomna, vrátí clone4() souborový deskriptor, odkazující k procesu, který právě vytvořil. Ve výchozím nastavení se s deskriptorem nedá příliš pracovat, ale je-li zároveň nastavena vlajka CLONE_AUTOREAP, chování systému se změní.

Když skončí proces vytvořený pomocí CLONE_AUTOREAP, dojde k jeho okamžitému vyčištění, místo aby čekal v zombie stavu na voláníwait() rodičovského procesu. Toto chování může být užitečné samo o sobě, pokud se rodič nestará o to, kdy potomek ukončí svou činnost. Pokud rodič čeká na potomkův exit, může vytvořit procesní souborový deskriptor s pomocí CLONE_FD - tak bude umožněno čtení deskriptoru v okamžiku, kdy dojde k ukončení procesu. Viditelná bude struktura:

	struct clonefd_info {
	uint32_t code;   /* Signal code */
	uint32_t status; /* Exit status or signal */
	uint64_t utime;  /* User CPU time */
	uint64_t stime;  /* System CPU time */
    };

S pomocí tohoto mechanismu může funkce knihovny vytvořit proces a počkat na jeho dokončení, aniž by došlo k narušení řízení procesu jinde v programu. Tím se řeší problém nutnosti sdílet mechanismus pro řízení informací o ukončení procesu odstraněním onoho sdílení a dochází k proměně běžícího procesu v určitý typ souboru, který může být sledován a řízen výlučně kódem, který o něm ví.

Toto řešení mělo malý háček ve způsobu provádění řešení: V systémové volání clone již není místo pro žádné další vlajky. Josh proto vytvořil nové, které se jmenuje clone4(). V C knihovně vypadá interface takto:

	int clone4(uint64_t flags, size_t args_size, struct clone4_args *args,
               int (*fn)(void *), void *arg);

Pole flags drží vlajky v provozu. Tradiční vlajkyclone(), i ty nové. Jako v případě clone() zavolá po svém vytvoření proces potomka fn(arg). Argument args vypadá takto:

	struct clone4_args {
	pid_t *ptid;
	pid_t *ctid;
	unsigned long stack_start;
	unsigned long stack_size;
	unsigned long tls;
	int *clonefd;
	unsigned clonefd_flags;
    };

Většina těchto polí odpovídá argumentům, předaným volání clone(); jen byla přesunuta do samostatné struktury. Pole clonefd a clonefd_flags jsou nová. První označuje místo pro uložení vytvořeného souborového deskriptoru po předání CLONE_FD, druhé smí držet vlajky O_CLOEXEC a O_NONBLOCK, které se použijí na tento deskriptor.

velikost struktury clone4_args musí být předána odděleně skrze args_size. Pokud je třeba v budoucnu ke struktuře přidat pole, umožní předaná velikost kernelu rozhodnout, která verze struktury je používaná a podle toho reagovat.

Pro úplnost, takto vypadá celé systémové volání (z knihovny C):

	int clone4(unsigned flags_high, unsigned flags_low,
               unsigned long args_size,
               struct clone4_args *args);

Na této úrovni se clone4() chová jako fork(), vrací se do obou procesů (rodiče i potomka), ovšem s jinými hodnotami.

Tato funkce je celkem užitečná, ale popis opravy obsahuje mimo jiné tuto zajímavou poznámku:

Souborový deskriptor CLONE_FD jednoznačně identifikuje proces systému (in a race-free way) držením odkazu k task_struct. V budoucnu možná zavedeme API rozhraní, která podporují použití procesních souborových deskriptorů místo PID.

ID (PID) procesu podléhají úzkému souběhu: proces by se mohl ukončit a být nahrazen jiným, se stejným PID: V systému se spoustou běžících procesů a rozdílných aktivit je šance na krátkodobé využití PID vysoká, zvlášť, když se počet dostupných PID nezvýšil nad tradičních 32 768. Souborový deskriptor, připojený k procesu v době vzniku není předmětem "race condition", měl by tedy být bezpečnější při práci pro jiné procesy.

Přidání systému pro řízení souborově deskriptorových systémových volání je úkolem do budoucnosti, prozatím řeší akutní problémy CLONE_FD. Tento patch si prozatím odbyl dvě kola oprav, dočkal se několika významných změn, ale jeho hlavní funkčnost se nezdá být kontroverzní. Ještě to vypadá na jedno kolo revizí, potom by se tahle funkce mohla dostat do vývojového cyklu 4.2.

       

Komentáře

[Petr Tomášek]

podřebuje vytvořit podřízený proces

No, lepší než potřísněný proces ...

[Petr Tomášek]

Přidává novou vlajku

Ale fuj... hezky česky je to „příznak“...

[xkucf03]

+1, zrovna jsem to chtěl napsat

[2X4B-523P]

cesky se tomu rika flagy, priznak jsem slysel tak maximalne u nastaveni partition, totiz diskoveho oddilu a stejne rikam ze se nastavuje bootovatelnou... asi je to jak kde... jedno bude hovorove a to druhe spisovne, nebo tak neco...

[xkucf03]

Slovo „flagy“ není česky – „příznak“ se v tomhle smyslu používá úplně normálně.

[NN]

+1

[mimi.vx]

a pouzivalo se uz v 80. letech

[2X4B-523P]

jak kde

[Jardík]

Dobrá zpráva. Race-free implementace práce s procesy je opravdu potřeba, dodnes to některé knihovny (třeba glib či Qt) řeší prakticky různými hacky, co se rozbijou, jakmile něco spustí proces svojí cestou, nebo co mají lineární časovou složitost, kdy použijí waitpid na každý "známý" proces, který knihovna spustila. Nedej, kdyby třeba uživatel sám zavolal wait ve své aplikaci a reapnul by proces vlastněný knihovnou, okamžitá race condition, kdy pak knihovna provede wait na úplně špatný proces.

[pavlix]

Hlavně že na waitfd se z vysoka sere a všichni se tváří, že se dá použít signalfd.

[pavlix]

Nevím přesně, jakou výhodu má CLONE_FD oproti signalfd a jaké specifické races to řeší, které signalfd neřeší, ale třeba se najde někdo, kdo tyhle znalosti má a podělí se.

[Jardík]

signalfd neřeší vůbec nic, protože zase se budete prát s knihovnou o signalfd, když ho bude chtít použít i cílová aplikace. Race condition kvůli číselnému pid zůstanou, a stejně musíte po dostání signálu přes signalfd zavolat něco z wait rodiny (a zase musíte třeba procházet celý seznam procesů, protože musíte brát v úvahu, že nodostanete tolik signálů, kolik máte procesů, ale i méně, pokud budou 'spojeny'). Taky je tu problém s maskami signálů, kdy se pere aplikace s knihovnou a ta třeba s knihovnou další současně použitou.

CLONE_FD tohle řeší, proces je reapnut automaticky a vy dostanete info, že se tak stalo a víte přesně který proces, nikde se vám informace neztratí, jako v případě signálu či signalfd.

[Jardík]

Otázkou pak zůstává, jak moc bude v budoucnu API rozšířeno a jestli se to stane použitelné i pro jiné účely.

[pavlix]

Samozřejmě jsem měl namysli waitfd, nikoli signalfd, tedy file deskriptor na konkrétní child proces, o kterém tvrdili, že to v jádře vůbec není potřeba. Jinak waitfd nebylo kdysi přijato nikoli z důvodu, že by se chystalo lepší řešení v podobě CLONE_FD, ale protože to údajně nebylo potřeba a na všechno stačí signalfd. Někdy mi přijde, že by si kerneláři měli občas do userspace taky něco napsat.

[Jardík]

Já si vybavuju nějakej článek v souvislosti s Qt a QProcess, kde se snad jeden vývojář pokoušel něco navrhnout, ale že to vedlo k návrhu nějakého waitfd, to už jsem nevěděl. Jinak ten signalfd je v knihovnách prakticky nepoužitelný, pokuď teda nevytvoří knihovna vlákno, které vlastní, a jehož signal maskami si může dělat, co chce. V rámci aplikace se to pak jinak prostě tluče a je to nepoužitelné. signalfd považuji za jakýsi pokus, který prostě nebyl úplně domyšlen.