Jaderné noviny – 18. 10. 2012: Řešení nedostatku v návrhu epoll

5. 11. 2012 | Luboš Doležel | Jaderné noviny | 3174×

Aktuální verze jádra: 3.7-rc1. Citáty týdne: Paul McKenney, Rusty Russell, Ted Ts'o, Hugh Dickins, Stephan Mueller, Greg Kroah-Hartman. Nový návrh kernel_thread/execve od Ala Vira. Závěr začleňovacího okna řady 3.7. Aplikace s vlákny a EPOLL_CTL_DISABLE.

Obsah

• Aktuální verze jádra: 3.7-rc1
• Citáty týdne: Paul McKenney, Rusty Russell, Ted Ts'o, Hugh Dickins, Stephan Mueller, Greg Kroah-Hartman
• Nový návrh kernel_thread/execve od Ala Vira
• Závěr začleňovacího okna řady 3.7
• Aplikace s vlákny a EPOLL_CTL_DISABLE
  • Popis problému
  • Řešení
  • Závěr

Aktuální verze jádra: 3.7-rc1

Aktuální vývojová verze jádra je 3.7-rc1 vydaná 14. října. Přehled posledních věcí, co se dostaly do verze 3.7, najdete níže.

Stabilní aktualizace: verze 3.0.46, 3.4.14, 3.5.7 a 3.6.2 vyšly 12. října. 3.5.7 je poslední verzí v řadě 3.7.

Citáty týdne: Paul McKenney, Rusty Russell, Ted Ts'o, Hugh Dickins, Stephan Mueller, Greg Kroah-Hartman

Evidentně není dobrý nápad sestavovat a posílat patch, zatímco jste na setkání výboru pro standardizaci C++, kde se lidé hádají o asynchronních futures...

-- Paul McKenney

Věřím, že odpovědí je to, že nedávné zranitelnosti nás dohnaly až ke zavržení myšlenky, že se čemukoliv v uživatelském prostoru dá věřit, a uchýlení se zpět do jádra. Tvrzení, že je jádro bezpečnější, protože jsme nezačlenili spoustu humusu, je skutečně kacířskou myšlenkou.

-- Rusty Russell

Dlouholetá zkušenost se systémy souborů ukazují, že jsou jako dobrá vína; trvá, než dospějí. Ať už se bavíme od ext2/3/4, btrfs, Sun ZFS, Digital ADVFS, IBM JFS nebo GPFS atd. a nesejde na tom, jestli se bavíme o open source nebo o tradičních firemních vývojových procesech, trvá alespoň 3-5 let a 50-200 člověkoroků, než se povede od píky stvořit souborový systém vhodný k produkčnímu nasazení.

-- Ted Ts'o

Chystal jsem patch, který by toto opravil, a skončilo to tak, že jsem nenašel problém, který by opravoval – což odpovídá tomu, že takový problém nebyl nikdy nahlášen.

-- Hugh Dickins

Požadavkem na modul FIPS 140-2 je to, že je celý modul zakázán, pokud self test nebo test integrity libovolné jeho komponenty selže.

Máme dvě řešení, která byla v souvislosti se zakázáním modulu zvažována: udržování globálního stavu crypto API, které zajistí, že nebude reagovat v případě selhání testů. Druhým řešením je prostě vypnout celé jádro. První varianta nakonec také povede ke selhání jádra, protože mnoho částí jádra závisí na crypto API, proto byla zvolena varianta druhá.

-- Stephan Mueller; nesnažte se načítat nepodepsaný modul v režimu FIPS

Jak dlouho by měl člověk čekat, když dostane mail s evidentně nesprávnými tvrzeními o jaderném kódu Linuxu, než pošle zpátky odpověď „to si snad děláš srandu“.

Měl bych prostě doufat, že si odesilatel uvědomí svou chybu a dát mu N hodin, aby svá tvrzení odvolal, opravil svůj šílený patch a poslal ho znovu, tedy dát mu určitou ochrannou lhůtu? Pokud ano, tak jaká je správná hodnota N?

Nebo je férové se urvat ze řetězu a nechat skrze svou klávesnici projevit své torvaldsovské démony s tím, že to tomu druhému třeba prospěje a poučí se ze svých chyb?

-- Greg Kroah-Hartman

Nový návrh kernel_thread/execve od Ala Vira

Al Viro pilně pracoval na přepisu vytváření jaderných vláken, aby byl kód čistší a méně závislý na architektuře. Současně zaslal dlouhý dokument s popisem, jak nyní vytváření jaderných vláken funguje a co na tom mění. Je to zajímavé čtení pro ty, které zajímá, jak jedna z důležitých součástí jádra pracuje. Původní implementace kernel_thread() byla poněkud zapeklitá. V nejlepším případě naplnila strukturu pt_regs podle svých argumentů a předala je funkci do_fork(). Cílem bylo navést kód k tomu, aby se vrátil ze systémového volání a současně neopustil režim jádra, takže by nově vzniklé vlákno (po vyprázdnění svého stacku) skončilo v pomocné funkci s těmi správnými hodnotami v registrech. V režimu jádra.

Závěr začleňovacího okna řady 3.7

Linus před uzavřením začleňovacího okna přetáhl do řady 3.7 celkem 10 409 neslučovacích změn. To dělá z jádra 3.7 jedno z nejaktivnějších vývojových cyklů v poslední době; přibližuje se jen jádro 3.2 s 10 214 změnami. Děje se toho evidentně hodně.

Zajímavostí je nedůvěra, jakou Linus vyjádřil ohledně některých změn při psaní oznámení verze 3.7-rc1. Například taková diskuze o patchi pro 64bitový ARM utichla už před dlouhou dobou, Linus se ale ozval se svým názorem ještě teď:

Tak schválně, kolik let lidem od armu potrvá, než udělají to, co nakonec každá 64bitová architektura: sloučí se s 32bitovým kódem. Jako obvykle lidé tvrdili, že je spousta důvodů, proč je to v *tomto* případě jinak a jako obvykle se nakonec ukáže, že je to blbost, a za pár let uzříme velké patche, které to budou zase všechno slučovat. Možná to ale v tomto případě *bylo* opravdu jinak. Hehe.

Svou nelibost vyjádřil i k rozdělování hlavičkových souborů API pro uživatelský prostor – enormní sadě patchů, která byla do 3.7 začleněna jen částečně. Pročišťování hlavičkových souborů je prý až moc nepříjemné na to, aby to výsledky práce opodstatnily, takže už další nebude brát v potaz.

Změny začleněné od minulého týdne viditelné uživatelům zahrnují:

• Byla začleněna podpora podepsaných jaderných modulů. Pokud ji zapnete, tak jádro odmítne načíst moduly, které nebyly podepsány známým klíčem. To je něco, co je mimo jiné potřeba pro plnou podporu UEFI secure boot. K dispozici je i režim, kdy nepodepsaný modul bude přesto načten, ale jádro bude označeno jako tainted.
• Podpora NFS 4.1 už není považována za experimentální.
• MD RAID nyní podporuje operace TRIM.
• Podpora nového hardwaru.

Změny viditelné vývojářům jádra zahrnují:

• Patche pro „rozdělení UAPI“ byly přetaženy do docela velkého počtu subsystémů, což má za následek velký šum kolem hlavičkových souborů. Velká část změn byla odložena na verzi 3.8, takže to ještě není vše.
• Subsystém kerneldoc nyní umí vytvářet dokumenty ve formátu HTML5.
• Jádro má nový obecný subsystém pro chlazení na bázi cpufreq; více v dokumentaci.
• Hodně vývojářům se nelíbí zdržení při sestavování způsobené funkcí podepisování modulů. Kdokoliv, kdo potřebuje rychle dělat hodně sestavení jádra, si tu funkci asi bude chtít vypnout.

Nyní probíhá stabilizace všech změn. Pokud věci budou probíhat jako obvykle, tak se konečné verze 3.7 dočkáme někdy začátkem prosince.

Aplikace s vlákny a EPOLL_CTL_DISABLE

Mimo začlenění serverové části TCP Fast Open bylo jednou z mála změn v API pro uživatelský prostor přidání nové operace EPOLL_CTL_DISABLE pro systémové volání epoll_ctl(). Na tuto operaci se dá dívat jako na pěknou ukázku mnohdy neočekávaných komplikací při vývoji aplikací s vlákny. Přidání EPOLL_CTL_DISABLE současně demonstruje obvyklé problémy při návrhu jaderných API pro uživatelský prostor (aby nebyly pochybnosti: EPOLL_CTL_DISABLE je opravou dřívějšího návrhu, nikoliv podstatou problému).

Popis problému

Autor patche Paton Lewis není běžným jaderným hackerem. Je to vývojář, kterého něco v uživatelském prostoru trápí, a změna v jádře je pravděpodobně jediným lékem. V popisu první podoby patche Paton shrnul problém takto:

Aktuálně není možné spolehlivě mazat položky pro epoll při používání stejné sady z více vláken. Po zavolání epoll_ctl s EPOLL_CTL_DEL může jiné vlákno stále vykonávat práci spojenou s událostí na této položce (po volání epoll_wait). Mazající vlákno tedy nemůže vědět, kdy je bezpečné smazat prostředky spojené s touto položkou, protože tyto prostředky může používat jiné vlákno.

Mazající vlákno by mohlo po zavolání epoll_ctl s EPOLL_CTL_DEL čekat po nějakou dobu než provede uvolnění paměti, ale to je neefektivní a mohlo by vést k odstranění prostředlů, než jiné vlákno svou práci dokončí.

Skutečnost, že si jádro ukládá interní stav, je zdrojem komplikací pro vícevlákenné aplikace. Zdrojem komplikací je to, že aplikace mohou samy chtít si udržovat informace o popisovačích, aby nedocházelo k tzv. descriptor starvation, kdy velké I/O na jednom popisovači vede k tomu, že se aplikace nedostává k obsluze ostatních popisovačů. Udržování údajů v jádře i v aplikaci pak může vést k race conditions, kdy se různá vlákna snaží aktualizovat stavové informace na obou místech. Nejdůležitější informací je pak samostná „existence“.

Představme si situaci, kdy vlákno zjistí, že už nepotřebuje sledovat nějaký popisovač. Vlákno by nejprve zkontrolovalo, zda není v údajích v aplikaci popisovač označen jako takový, kde ještě čekají nějaká data k přečtění, a pokud nejsou, tak by popisovač odstranilo z dat v uživatelském prostoru a také v jádře pomocí epoll_ctl(EPOLL_CTL_DEL). To ale nemusí dopadnout dobře, pokud budeme mít následující situaci s popisovačem číslo 9:

Vlákno 1	Vlákno 2
Zjišťuje z údajů v aplikaci, že na popisovači 9 není co číst.
	Volá epoll_wait; na popisovači 9 jsou prý nějaká data.
	Označuje v rámci aplikace popisovač 9 jako popisovač, kde čekají nějaká data, takže je možné provést I/O.
Odstraňuje popisovač 9 údajů v aplikaci.
Odstraňuje popisovač 9 ze sady pro epoll pomocí epoll_ctl(EPOLL_CTL_DEL).

V takovéto situaci by došlo ke ztrátě nějakých dat. V jiných situacích by mohlo dokonce dojít k poškození dat v aplikaci nebo k jejímu pádu.

Až na ochranu volání epoll_wait() globálním mutexem, což zlikviduje vícevlákennost aplikace, zde neexistuje žádné řešení, které by podobným situacím zabránilo.

Řešení

Paton problém řeší tak, že rozšiřuje epoll API o novou operaci, která atomicky zabrání ostatním vláknům v přijímání dalších událostí o tomto popisovači a současně volajícímu kódu sdělí, zda nebyl popisovač v „nedávné“ době ohlášen jako aktivní jinému vláknu.

Při přidávání nebo úpravě popisovače v seznamu sledovaných popisovačů aplikace předává údaj o tom, jaké události ji zajímají. Může jít mj. o EPOLLIN a EPOLLOUT, pokud aplikaci zajímá, kdy bude možné na popisovači číst nebo zapisovat. Kromě toho se používá ještě několik „provozních“ příznaků. Jedním takovým je EPOLLONESHOT. S ním je popisovač vrácen voláním epoll_wait() pouze jednou, pak sice není ze seznamu vyřazen, ale je vypnut. Pokud má aplikace zájem jej opět zapnout, musí tak učinit pomocí epoll_ctl(EPOLL_CTL_MOD).

Implementace EPOLLONESHOT závisí na jednoduchém triku. Pokud je popisovač vrácen v epoll_wait(), tak jádro odstraní všechny příznaky označující sledované události u tohoto popisovače.

Nyní se tedy můžeme dostat k Patonovu rozšíření tohoto API, operaci epoll_ctl(EPOLL_CTL_DISABLE), která vícevlákenným aplikacím umožní vyhnout se výše popsaným race conditions. Pro úspěšné použití rozšíření je nutné následující:

1. Datové struktury aplikace obsahující stavy popisovačů by měly obsahovat i příznak „odstraň po dokončení“.
2. Volání epoll_ctl() pro přidání nebo úpravu popisovačů musejí používat příznak EPOLLONESHOT.
3. Operace epoll_ctl(EPOLL_CTL_DISABLE) by měla být použita tak, jak si popíšeme za chvíli.

Nová operace epoll se používá takto:

epoll_ctl(epfd, EPOLL_CTL_DISABLE, fd, NULL);

kde epfd je popisovač instance epoll. fd je pak popisovač, který chceme vypnout. Sémantika této operace řeší dvě situace:

• U položky popisovače fd jsou nastaveny příznaky I/O operací. To znamená, že od posledního volání epoll_ctl() žádné vlákno nespustilo epoll_wait(), které by popisovač vrátilo jako aktivní. V tomto případě jádro odstraní příznaky I/O operací, které zabrání budoucímu vrácení v epoll_wait(). Volání epoll_ctl(EPOLL_CTL_DISABLE) v tomto případě vrátí nulu. Volající kód v ten moment ví, že s popisovačem nepracuje nikdo další, takže může popisovač bezpečně odstranit jak z datových struktur aplikace, tak z jádra.
• U položky fd nejsou nastaveny žádné příznaky. To znamená, že od poslední operace epoll_ctl() došlo k volání epoll_wait(), které vrátilo popisovač jako aktivní. V tomto případě epoll_ctl(EPOLL_CTL_DISABLE) vrátí -1 s errno nastaveným na EBUSY. V ten moment aplikace ví, že s popisovačem pracuje jiné vlákno, takže nastaví příznak „odstraň po dokončení“ v datových strukturách aplikace, aby toto vlákno vědělo, že má popisovač odstranit.

Závěr

První verze Patonova patche se nedočkala bouřlivých reakcí. Jediná zásadní reakce přišla od Christofa Meerwalda; v reakci na ni Paton vytvořil druhou verzi patche. Tato verze se už nedočkala žádných reakcí a byla začleněna do 3.7-rc1.

Ačkoliv EPOLL_CTL_DISABLE problém řeší, nejde o řešení, které by se používalo jednoduše nebo bylo intuitivní. Hlavním důvodem je to, že EPOLL_CTL_DISABLE je dodatečným hackem do epoll API, které splňuje Linusem často opakovaný požadavek, že existující aplikace nesmějí být změnami v jaderném ABI porouchány. Za těchto podmínek může být tento patch nejlepším řešením problému. Je ale téměř jisté, že kdyby se s tímto počítalo hned při návrhu epoll API, našlo by se řešení lepší.

Na závěr je vhodné dodat, že funkce EPOLL_CTL_DISABLE to ještě nemá jisté. Než vyjde verze 3.7, může být ještě nahrazena něčím jiným, kdyby náhodou někdo měl lepší nápad.

       

Komentáře

[Honz]

Gregův cintát je skvělý...

[David Ježek]

jj, ten závěr rozhodně nemá chybu

[Luboš Doležel (Doli)]

MD RAID nyní podporuje operace TRIM.

Hurá! A to jsem před časem někde četl, že je prý složité to udělat a nestojí to za to.

[snajpa]

Zajimalo by mne, jestli to Red Hat backportuje do RHEL6. Mohli by.

[alkoholik]

To vis, neni RAID (0, 1, 10) jako RAID(5, 6).
Nekde staci vymazat bloky TRIMem a nekde by ti musely sedet kontrolni soucty.

[frr]

Ten odkaz na async a future mi zase trochu rozšířil obzory. Děkuji Už dlouho jsem se chtěl na aktuální výdobytky C++ trochu podívat...

[Voransky]

Díky za překlad, jen v Russellovo citátu: seems to be a heretical thought = kacířskou?

[Luboš Doležel (Doli)]

Díky, špatně jsem to slovo přečetl.

[Petr Ježek]

Přeložil. :)

[trekker.dk]

Když už jsme v opravách: vína nedospívají, vína zrají...