Jaderné noviny – 10. 3. 2011: Red Hat a GPL

21. 3. 2011 | Jirka Bourek | Jaderné noviny | 3437×

Aktuální verze jádra: 2.6.38-rc8. Citáty týdne: Alan Cox, Tejun Heo. Red Hat a GPL: Preferovaná podoba, Výměna práv za podporu. Zlepšení ptrace(). Zpoždění OOM zabijáka.

Obsah

• Aktuální verze jádra: 2.6.38-rc8
• Citáty týdne: Alan Cox, Tejun Heo
• Red Hat a GPL
  • Preferovaná podoba
  • Výměna práv za podporu
• Zlepšení ptrace()
• Zpoždění OOM zabijáka

Aktuální verze jádra: 2.6.38-rc8

Současné vývojové jádro je 2.6.38-rc8 vydané 7. března. Linus naznačil, že k finálnímu vydání 2.6.38 by mělo dojít během týdne nebo tak. Neměl bych problém s tím vydat tuto verzi jako finální 38, ale několik dní během příštího týdne budu částečně nedostupný, takže jsem měl pocit, že nemá cenu ještě otevírat začleňovací okno. A také máme regrese. Některé z nich jsou zde snad opraveny, ale nebude škodit dát tomu týden navíc. Zkrácený changelog je v oznámení, všechny detaily lze nalézt v kompletním changelogu.

Stabilní aktualizace: 3. března bylo vydáno 2.6.32.31, které opravuje jedinou chybu při překladu. 7. března bylo následováno jádry 2.6.32.32 a 2.6.37.3; obě obsahují větší sadu důležitých oprav.

4. března vyšla sada patchů pro běh v reálném čase 2.6.34.8-rt.

Citáty týdne: Alan Cox, Tejun Heo

Obvykle není dobrá odpověď, když jde o bezpečnost a správnost firmware. Opravdu to není dobrá odpověď, když chcete nový firmware flashovat. Tvrzení „váš drahý hardware se obvykle nezmění v bezcennou cihlu“ něco málo postrádá.

-- Alan Cox

Co se zde snažím říci, že VŽDYCKY jde o rovnováhu a něco za něco. Držet se fundamentalisticky nějakého pravidla je jistá cesta ke strašnému kódu, který nejenom bude těžké vyvíjet a udržovat, ale který také svým uživatelům v dlouhodobém měřítku přinese spoustu WTF chvil.

Tak to vyvažme. Vyhýbat se změnám chování viditelného pro uživatelský prostor má velkou váhu, ale ta NENÍ nekonečná.

-- Tejun Heo

Red Hat a GPL

napsal Jake Edge, 8. března 2011

Změny ve způsobu, jakým Red Hat vydává zdrojové kódy k jádru pro RHEL 6, vyvolaly debatu. Objevuje se jisté napětí mezi potřebami podnikové distribuce a zájmy projektů svobodného software, na kterých je založena. Tyto změny nejsou příliš populární a dost se spekulovalo o tom, že Red Hat jimi nějak porušuje GPL, což je poměrně vážné obvinění. Jsou ale dobré důvody, proč věřit, že Red Hat hranici porušení GPL nepřekročil, i když se možná pohybuje dost blízko.

První důvod je jasný: Red Hat má špičkový tým právníků, kteří mají spoustu zkušeností s GPL, takže by bylo těžké uvěřit, že tito právníci neprozkoumali nový postoj firmy a že nevěří, že ho bude možné v případě žalob ubránit. Zatímco Red Hat má tým právníků, rozpočtu LWN na právní služby podle všeho něco málo chybí, takže nic v tomto článku nechť není považováno za právní rady. (Nejsem právník a ani jsem žádného nehrál ve filmu.)

Argumenty ohledně plnění GPL, zdá se, spadají do dvou kategorií. První je, že distribuce něčeho, co je efektivně tar archiv zdrojových kódu jádra, nevyhovuje preferované podobě díla pro jeho modifikace (jak to GPL vyžaduje.) Do druhé kategorie potom spadá to, že jednotlivé patche jsou k dispozici zákazníkům, ale těm není dovoleno je dále distribuovat, což lze považovat za dodatečná omezení práv ke GPL kódu (kterým patche zjevně jsou.) I když obě stížnosti nejsou zcela neopodstatněné, ani jedna pravděpodobně porušení GPL nepředstavuje.

Preferovaná podoba

I když se rozhodně můžeme dohadovat o tom, co pro distribuci zdrojového kódu znamená preferovaná podoba, kroky Red Hatu se k hranici podle všeho vůbec nepřibližují. Základní myšlenkou je zde to, že kód má být vydán v digitálně podobě včetně případných skriptů pro překlad tak, aby vývojáři v downstreamu mohli reprodukovat GPL binárku, která je dodávána. Hlavním účelem této podmínky je, aby nespolupracující distributoři nemohli zdrojové kódy vydat tiskem nebo vytesat do hliněných destiček klínovým písmem. I když by bylo možné tvrdit, že tyto metody poskytují zdrojové kódy, rozhodně se nejedná o podobu, kterou by mohl někdo preferovat – a ani to nevyhovuje požadavku na médium, které se obvykle používá k výměně software.

Zatemněný zdrojový kód, ve kterém se jména všech proměnných a funkcí změní na nesrozumitelné bláboly nebo ve kterém se zdrojový kód úmyslně rozdělí tak, aby se s ním hůře pracovalo, je v o něco větší míře šedá zóna – ale ne o moc. Takové kroky lze považovat za jasné pokusy obejít požadavky GPL. To Red Hat ale nedělá.

Tar archiv, který je distribuován, možná není preferovanou podobou, kterou by používali vývojáři Red Hatu, ale to není součástí daného požadavku. Ve světě svobodného software je vydávání GPL kódu v archivech dlouhotrvající tradicí. Mnoho projektů to tak stále dělá a sama FSF takto software v minulosti vydávala také. I když je hezké vidět do systému pro správu verzí projektu, podmínky GPL nic takového nevyžadují. Dokud Red Hat poskytoval jednotlivé patche, nikdo si nestěžoval, že jejich Git archiv není veřejně přístupný. Pro vývojáře z Red Hatu je git archiv rozhodně při práci se zdrojovými kódy preferován, ale je mnoho důvodů, proč si firma může chtít tyto archivy nechat pro sebe – což je něco, na co rozhodně má právo.

V GPL je často ignorovaná klauzule o modifikacích kódu, kterou je zde také vhodné vzít v úvahu: Musíte zajistit, že modifikované soubory budou obsahovat zjevné poznámky o tom, že jste soubor změnili a datum změny. To Red Hat možná technicky porušuje, ale rozhodně není jediný, protože tohle nařízení víceméně ignorují všichni bez nějakých vážných následků. Tento požadavek GPL nicméně téměř nikoho nezajímá; co všichni chtějí, je znát důvod, proč byla změna provedena (společně s tím, které změny ostatních souborů s ní souvisí), a GPL neříká nic o tom, že je potřeba být takto detailní.

Co se týče zdrojových kódu jádra RHEL, Red Hat je poskytuje v podobě, která je spolehlivě v mezích GPL. Je také spolehlivě v mezích toho, co je v komunitě standardem. Komunita dostává tar archivy od mnoha firem (často od těch ze světa embedded Linuxu), někdy to stojí trochu úsilí a vždy jsme rádi, když je máme. Když jde o distribuci zdrojových kódů, pro Red Hat by neměly platit jiné standardy než pro ostatní firmy. Tar archivy mohou být překážkou ve spolupráci, ladění a tak dál, ale jejich distribuce není ani omylem porušením GPL. Co se druhé velké stížnosti týče, tam to už tak jednoduché není.

Výměna práv za podporu

I když se nejedná o nic nového, některé aspekty podpory od Red Hatu vyvolávají, co se týče změn v distribuci zdrojových kódů, vrásky. Konkrétně se jedná o to, že jednotlivé patche, které původně byly součástí zdrojových RPM, jsou evidentně zákazníkům Red Hatu k dispozici, ale jenom v případě, že je nebudou dále distribuovat. V opačném případě přijdou o podporu. To zní jako omezení práv příjemců patchů, která jim GPL garantuje – a také je – ale toto omezení je vynuceno dohodou mezi Red Hatem a jeho zákazníky.

Tuto část obchodního modelu Red Hatu Bradley Kuhn nazývá model jestli máš rád copyleft, tvoje prachy nechceme. Podle něj vyhovuje GPL, prostě protože GPL neříká nic o tom, jestli někdo musí být tvým zákazníkem. Také říká, že Red Hat tento model začal používat jako první, ale možná přitom zapomněl na Sveasoft.

Historii zde dnes trochu zakrývají hnijící odkazy, takže je možné, že Red Hat byl opravdu první. Obchodní model Sveasoftu v podstatě od zákazníků vyžadoval, aby se vzdali svého práva dále distribuovat GPL kód, který jim Sveasoft poskytl. Tento model byl kritizován někdy počátkem roku 2000; v roce 2004 nicméně Sveasoft oznámil, že FSF toto uspořádání revidovala a – přinejmenším tenkrát – poměrně překvapivě schválila. Ve zkratce je dohoda o podpoře (či předplatném) smlouvou mezi dvěma subjekty a ty se mohou dohodnout víceméně na čemkoliv. GPL nemůže nikoho chránit před tím souhlasit s nějakým chováním.

V dávné minulosti se také objevovaly stížnosti na to, že Red Hat ukončí podporu uživatelům, kteří používají vlastní jádro místo toho, které jim dodává v rámci RHEL. I když je to dalším omezením práv poskytovaných GPL, toto se dá snadno pochopit: snažit se poskytovat podporu jakéhokoliv náhodného jádra by pravděpodobně bylo rychlou cestou, jak přivést techniky Red Hatu k šílenství. Kompletní ukončení podpory by pravděpodobně bylo trochu přehnanou reakcí – a pravděpodobně k tomu docházelo jenom výjimečně, pokud vůbec někdy – ale nepodporovat systémy, na kterých běží jiná jádra, není nerozumný postoj.

Zákaz distribuce jaderných patchů někteří považují za nejohavnější „porušení“ práv, která GPL garantuje zákazníkům. V některých a možná i mnoha případech tyto patche Red Hat dokonce nevlastní, protože je do upstreamu zaslali jiní a do jádra RHEL 6 byly integrovány nebo backportovány. Výsledky této snahy ale jsou distribuovány v podobě zdrojových kódů. Jestliže jsou zákazníci Red Hatu ochotni vyměnit práva garantovaná GPL za podporu, všichni ostatní mohou těžko udělat něco víc než stěžovat si.

Na druhou stranu by dostatečně motivovaná skupina lidí mohla patche znovu získat reverzním inženýrstvím ze zdrojových kódů RHEL 6. Byl by to náročný a na chyby náchylný proces, ale Red Hat řekl, že všechny vlastnosti RHEL 6 byly zaslány do upstreamu, takže by to mělo být proveditelné. Každý, kdo má s Red Hatem smlouvu o podpoře, by si nicméně měl účast na takovém projektu dobře rozmyslet. A jestli to vůbec má cenu, se ještě uvidí.

Zlepšení ptrace()

napsal Jonathan Corbet, 8. března 2011

Systémové volání ptrace() je jenom málokdy považováno za dobrý příklad unixového rozhraní. Toto volání se používá pro sledování a ladění procesů, ale do vínku mu byla dána podivná sémantika (rodičem sledovaného procesu se stane proces sledující), mnoho bradavic v rozhraní a příležitostně nepředvídatelné chování. Také je těžké ho v jádře implementovat; je jenom pár vývojářů, kteří jsou ochotni ponořit se do jeho kódu. Není tedy překvapení, že se občas mluví o tom nahradit ptrace() něčím lepším; popis jedné takové diskuze najdete v článku na LWN.net z roku 2010.

I když si někteří vývojáři myslí, že ptrace() je neopravitelné, Tejun Heo nesouhlasí. A aby svůj postoj podpořil, zaslal několik návrhů, jak toto rozhraní zlepšit. Řekl:

Ptrace je v současnosti v hodně špatném stavu a myslím si, že z největší části je to proto, že spousta práce je věnována snaze přijít s něčím úplně novým místo koncentrace na zlepšení toho, co už máme. Myslím si, že existující principy mohou být funkční. Jenom potřebují tam a onde trochu lásky a pozornosti.

Největší část „lásky a pozornosti“, kterou chce Tejun ptrace() věnovat, se týká interakce mezi sledováním a řízením úlohy. Řízení úlohy u procesů, které nejsou sledovány, používá jádro a shell k zastavení a restartu procesů s tím, že je možné přesouvat je na pozadí a zpátky. Když se do tohoto uspořádání vloží sledování, dojde z několika důvodů ke zmatkům. Změna rodiče sledovaného procesu například skutečného rodiče připraví o možnost získat upozornění na to, že byl proces zastaven nebo spuštěn. Také se zde objevuje několik podivných interních přechodů mezi stavy TASK_STOPPED a TASK_TRACED, které vedou k nepředvídatelnému a někdy překvapujícímu chování. Úlohu, která běží pod strace, je například možné zastavit pomocí ^Z jako obvykle, ale shell ji již nebude schopen restartovat.

Tejun má sadu konkrétních návrhů, jak situaci vylepšit. Prvním z nich je, že sledovaný proces by měl být vždy, pokud je zastaven, ve stavu TASK_TRACED. Současné podivné přechody mezi tímto stavem a TASK_STOPPED by zmizely. Dalším návrhem je opravit současný stav tak, aby skutečný rodič byl upozorňován na zastavení a spuštění procesu, i když je aktuálním rodičem sledující proces. Některé okrajové případy, jako to, co se stane, když je sledovaný proces odpojen [detached], by se opravily tak, aby chování procesu odpovídalo případu, kdy sledován není.

Opravu problému „nelze spustit zastavený sledovaný proces“ by Tejun vyřešil zachováním pravidla, že sledující proces má naprostou kontrolu nad stavem sledovaného procesu. Odpovědnost za nastartování sledovaného procesu, když by to shell požadoval, by tedy připadla na sledující proces. V současnosti sledující proces nemůže nijak zjistit, že se skutečný rodič pokusil nastartovat zastavený proces, takže je potřeba přidat odpovídající notifikační mechanismy. To by se zajistilo rozšířením notifikace STOPPED, kterou lze v současnosti získat jednou z variant systémového volání wait().

A nakonec by Tejun opravil chování operace PTRACE_ATTACH, která se připojí k procesu a zašle mu signál SIGSTOP, aby ho zastavila. Signál může působit zmatky a zastavení není žádoucí; sémantiku PTRACE_ATTACH ale není možné takto změnit bez rozbití existujících aplikací, takže by se místo toho vytvořila nová operace PTRACE_SEIZE. Ta by se připojila k procesu (pokud by již nebyl připojen) a přepnula proces do stavu TASK_TRACED.

Tyto změny by podle Tejuna stačily k tomu, aby se ptrace() změnilo v něco předvídatelnějšího a civilizovanějšího. Rád by začal s jejich implementací s cílem začlenit je do 2.6.40. V následující diskuzi se zdálo, že většina vývojářů s těmito změnami souhlasí, plus/mínus pár rýpalů. Jedinou velkou výjimkou byl Roland McGrath, který v této oblasti odvedl spoustu práce. Roland má odlišné návrhy obzvláště co se týče PTRACE_SEIZE.

Rolandovou alternativou k PTRACE_SEIZE (pokud se to dá opravdu nazývat „alternativou“, když jeho návrh byl první) je přidat dva nové příkazy: PTRACE_ATTACH_NONSTOP a PTRACE_INTERRUPT. To první by se připojilo k procesu, ale nijak by to neměnilo jeho stav; to druhé by proces zastavilo a přepnulo do stavu TASK_TRACED. Podle Rolanda má tento přístup mnoho výhod včetně možnosti sledovat proces, aniž by byl kdy zastaven. Jsou případy (například strace), kde není potřeba sledovaný proces zastavovat; když se tomu za takové situace vyhneme, můžeme proces sledovat a minimalizovat přitom vliv na jeho chování.

Roland také nadhodil variantu PTRACE_INTERRUPT, která by proces zastavila pouze v případě, že běží v uživatelském prostoru. To by předcházelo občasným selháním „interrupted system call“ [přerušené systémové volání], která může způsobit sledování ve své současné podobě. Také položil otázku, co by se stalo, kdyby samo PTRACE_SEIZE bylo přerušeno; vyrovnat se s takovou situací způsobem, který by umožnil psaní robustních aplikací, by podle něj bylo těžké. A nakonec se zmínil o škálovatelnosti: nemyslí si, že PTRACE_SEIZE bude fungovat dobře, když dojde na ladění aplikací s velkým počtem vláken. Ve shrnutí řekl:

Nic z toho neznamená, že PTRACE_SEIZE je k ničemu. Ale rozhodně není adekvátní k tomu splnit důležité požadavky, které motivují přidávání dalších rozhraní v této oblasti. Nápad s PTRACE_ATTACH_NONSTOP, který navrhuji, má rozhodně k vyřešení všech těchto záležitostí daleko, ale je to pružnější stavební kámen než PTRACE_SEIZE.

Bohužel to vypadá, že Roland mění zaměstnání a přestává v této oblasti pracovat, takže jeho nápady mohou mít menší váhu, než by měly normálně. V době psaní tohoto článku na jeho příspěvek bylo jenom málo reakcí. Tejun Rolandovy obavy z větší části odmítl. Také zaslal sérii patchů, které implementují část jeho návrhu, ale PTRACE_SEIZE ještě ne. Nekontroverzní části této práce budou začleněny téměř určitě; jak bude opraveno PTRACE_ATTACH, se ještě uvidí.

Zpoždění OOM zabijáka

napsal Jonathan Corbet, 9. března 2011

Zabiják při nedostatku paměti (OOM killer) je pověřen tím zabíjet procesy v reakci na vážný nedostatek paměti. Během let byl předmětem mnoha diskuzí a přepisů. Vzhledem k jeho účelu je to asi nevyhnutelné; výběr správného procesu, který má být ve správný čas zabit, nikdy nebude jednoduché naprogramovat. Rozšíření OOM zabijáka kvůli řídícím skupinám [control groups] zvýšilo jeho flexibilitu, ale také se tím objevily další zajímavé záležitosti, které je nutné řešit.

Normálně se OOM zabiják spustí, když systém jako celek má katastrofální nedostatek paměti. V kontextu řídících skupin OOM zabiják přichází do hry, když spotřeba paměti procesy v dané skupině překročila nakonfigurované maximum a pokusy získat od těchto procesů nějakou paměť nazpět selhaly. Situace nedostatku paměti, která je omezena na nějakou řídící skupinu, je špatná pro tyto procesy, ale neměla by ohrozit zbytek systému. To umožňuje zlepšit flexibilitu, se kterou se situace nedostatku paměti řeší.

Konkrétně je možné, aby uživatelský prostor převzal povinnosti OOM zabijáka pro danou řídící skupinu. Každá skupina má řídící soubor nazvaný oom_control, který lze použít několika zajímavými způsoby:

• Zápis "1" do tohoto souboru OOM zabijáka v dané skupině vypne. Pokud dojde k situaci, kdy bude nedostatek paměti, procesy v postižené skupině se prostě při pokusu alokovat paměť zablokují, dokud se situace nějak nezlepší.

• Pomocí speciálního popisovače souboru eventfd() může proces použít soubor oom_control a přihlásit se k odběru notifikací o událostech, že došla paměť (detaily o tom, jak to udělat, vizte v Documentation/cgroups/memory.txt) Proces potom bude informován, když řídící skupině dojde paměť; na problém potom může zareagovat a řešit ho.

Je mnoho způsobů, jak může OOM zabiják v uživatelském prostoru opravit problémy s pamětí, které postihly řídící skupinu. Například může jednoduše zvýšit limit. Mezi alternativy patří zabití procesů nebo jejich přesun do jiné řídící skupiny. Když to shrneme, je to rozumně flexibilní způsob, jak umožnit uživatelskému prostoru převzít odpovědnost za neštěstí v podobě nedostatku paměti.

Zdá se ale, že pro Google to není dost flexibilní. Jak už bylo řečeno jinde, Google nemá moc strojů, se kterými by mohl pracovat, takže se snaží nacpat na každý stroj velký počet úkolů. To vede k zajímavému problému: co se stane, když OOM zabiják v uživatelském prostoru sám nemá dost paměti a nemůže tedy reagovat na situaci, kdy dochází paměť jinde? Ukazuje se, že se všechno prostě nepříjemně zastaví.

Fungování Googlu se s něčím takovým samozřejmě příliš neslučuje, takže se tam pokusili najít další řešení. Výsledkem je patch, jehož autorem je David Rientjes, který do řídící skupiny přidává další soubor oom_delay_millisecs. Stejně jako oom_control i tento soubor zadrží jaderného OOM zabijáka a práci přenechá alternativě v uživatelském prostoru. Rozdíl je v tom, že správce může nastavit časový limit pro trpělivost OOM zabijáka; pokud situace přetrvá i po vypršení limitu, jaderný OOM zabiják převezme iniciativu a situaci vyřeší s takovou zaujatostí, jaká bude zapotřebí.

Davidovi toto zpoždění připadá jako užitečná nová vlastnost mechanismu řídících skupin. Podle Andrewa Mortona je to naopak jaderný hack, který má obcházet chyby v uživatelském prostoru, což se mu samozřejmě nelíbí. Pokud uživatelský prostor prohlásil, že bude řešit situace nedostatku paměti, musí si být podle Andrewa jistý, že to bude schopen dodržet. Přidávat zpoždění vypadá jako způsob, jakým se vyhnout této odpovědnosti, což by mohlo mít dlouhodobé následky:

U tohoto patche vidím problém, že rozšiřuje API pro uživatelský prostor. To znamená, že se zavazujeme toto rozhraní a jeho chování udržovat navždy. Jenže oom-killer a memcg jsou oblasti, kde probíhá intenzivní vývoj a minimálně v té první bývá obvyklé vytrhnutí kódu a jeho přepis. Zavázat se k tomu, že budeme udržovat nějaké rozšíření rozhraní pro uživatelský prostor, je velká věc, obzvláště když je toto rozšíření do značné míry svázáno s interními detaily implementace a definitivně svázáno s krátkodobými nedostatky v uživatelském prostoru a v jaderné implementaci.

Andrew by raději viděl snahu opravit v jádře problémy, které by mohly zabránit OOM zabijákovi v uživatelském prostoru dělat svoji práci. David nicméně nevidí jiný způsob, než tuto vlastnost používat. Jestliže se nedostane do hlavní řady, Google si ji bude muset udržovat odděleně. David nicméně předvídá, že ji bude požadovat víc a víc uživatelů s tím, jak bude narůstat využívání řízení paměti. V době psaní tohoto článku se diskuze zastavila v tomto bodě.

       

Komentáře

[Karry]

Může mi někdo vysvětlit jak se můžou procesy zaseknout pokud user space démona čekajícího na oom situaci nechám hlídat jadernému oom killeru? (Nezařadím jej přeci do skupiny kterou hlídá on sám...) Když dojde paměť tomuto démonu, tak ho sestřelí jádro a pak bych předpokládal že jeho ovečky jsou povražděny také...

[trekker.dk]

Ten démon není rodičem těch procesů.