Jaderné noviny – 18. 7. 2013: Dohady kolem fungování stabilních jader

5. 8. 2013 | Luboš Doležel | Jaderné noviny | 3981×

Aktuální verze jádra: 3.11-rc1. Citáty týdne: Ingo Molnar, James Bottomley.Začleňovací okno 3.11 se uzavírá. Problémy se stabilním stromem.

Obsah

• Aktuální verze jádra: 3.11-rc1
• Citáty týdne: Ingo Molnar, James Bottomley
• Začleňovací okno 3.11 se uzavírá
• Problémy se stabilním stromem

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

Aktuální vývojová verze jádra je 3.11-rc1 vydaná 14. července. Kromě začleňování v lustre šlo o poněkud klidnější začleňovací okno. Měli jsme méně stromů s problémy a k tomu pokračující debatu o stabilních patchích, která se rozjela hlavně kvůli tomuto začleňovacímu oknu, takže teď aspoň bude na jaderném sumitu o čem diskutovat. Celkově vzato bych ale řekl, že se začíná projevovat tradiční letní propad (vyjma Austrálie). Toto vydání má bohužel i nové kódové označení: „Linux pro pracovní skupiny“.

Stabilní aktualizace: verze 3.10.1, 3.9.10, 3.4.53 a 3.0.86 všechny vyšly 13. července. Greg upozorňuje na to, že verze 3.9.10 může být poslední v řadě 3.9.x.

Citáty týdne: Ingo Molnar, James Bottomley

Hluboko v našich sklepích nás toho konec konců nemůže moc zranit, snad kromě zemětřesení, erupcí gama záření a mámy, co se snaží uklidit kolem počítačů.

-- Ingo Molnar

Vůbec mi nevadí provozovat linux-scsi na základě rozumných standardů zdvořilého chování a snahy udržovat diskuzi v technické rovině, ale to se mnohem snáze realizuje na mailing listu s nízkým provozem; je mi jasné, že tento způsob argumentace se nemusí všem líbit, proto nejde o standardní chování, které bych chtěl všude nutit. Pravdou je, že bych něchtěl, aby se kdekoliv nutilo *jakékoliv* chování... jde v podstatě jen o zástěrku bojů o moc (nebo to k tomu bude brzo zneužité); jediný skutečný způsob, jak dosáhnout nějakého standardu v chování je jít příkladem, nikoliv pomocí nařízení.

-- James Bottomley

Začleňovací okno 3.11 se uzavírá

Linus oznámil vydání verze 3.11-rc1 – a uzavření začleňovacího okna – 14. července. Do té doby bylo začleněno 9494 neslučovacích sad změn. Poslední z těchto změn změnila kódové označení jádra na „Linux pro pracovní skuoiny“ a upravila logo při bootu. Vývoj Linuxu se jednoznačně přesunul do nové éry.

Z 9494 změn bylo 1219 přetaženo od souhrnu z minulého týdne. Mezi změny viditelné uživatelům patří:

• Nové ABI pro O_TMPFILE se na základě Linusových obav změnilo. Ve zkratce jde o to, že open() tiše ignoruje neznámé příznaky, takže software používající O_TMPFILE na starších jádrech se nemá jak dozvědět, že nedostává požadované chování dočasných souborů. Na základě návrhu Rasma Villemoese změnil Al Viro podobu O_TMPFILE v uživatelském prostoru tak, aby zahrnovalo bity O_DIRECTORY a O_RDWR – kombinaci, která na předchozích jádrech vždy vedla k chybě. Proto aplikace při pokusu použít O_TMPFILE na jádře bez podpory této volby obdrží chybu.
• Komprimovaná swap cache zswap byla začleněna do hlavní řady. Změny potřebné k tomu, aby vrstva alokace paměti byla modulární, jak bylo požadováno na letošním Sumitu pro úložiště, systémy souborů a správu paměti, ale podle všeho nebyly provedeny.
• Řadič sířky pásma I/O nazvaný „blk-throttle“ nyní řádně podporuje hierarchie řídících skupin – ale jen pokud je nastaven standardně vypnutý příznak sane_behavior.
• Cíl mapovače zařízení [device mapper] dm-switch mapuje I/O požadavky na sadu podřízených zařízení. Je určen pro situace, kdy je mapování složitější, než co je možné vyjádřit jednoduchým cílem jako „stripe“; více se dozvíte v dokumentaci.
• Podpora nového hardwaru.

Mezi změny viditelné vývojářům jádra patří:

• Chování při načítání modulů se lehce změnilo v tom, že načítání při nastavení neznámých parametrů modulu už neselže. Místo toho budou po vypsání zprávy do logu tyto parametry ignorovány. Toto umožní, aby konfigurace systému nadále fungovala při odstranění parametru modulu nebo bootu staršího jádra.
• Architektura MIPS nyní podporuje detekci přetečení bufferu -fstack-protector.

Poslední vývojové cykly vždy trvaly přibližně 70 dnů (i když 3.10 se svými 63 dny bylo znatelně kratší). Vydání jádra 3.11 bychom proto mohli očekávat přibližně 9. září.

Problémy se stabilním stromem

V dávné minulosti (březen 2005) vedli vývojáři jádra rozsáhlou debatu o různých problémech s vývojovým cyklem, jedním z nich byla nemožnost dostat opravy určené pro stabilní vydání jádra k uživatelům. Linus navrhl, že by se mohl udržovat oddělený strom pro opravy, pokud by se našel vhodný „ořežprut“, který by se o to staral, ale odhadoval, že by se za pár dnů zbláznil a vzdal by to. Ukázalo se, že Linus nepočítal s tvrdošijností Grega Kroah-Hartmana; Greg (tehdy s Chrisem Wrightem) se nabídl a dobrovolně začal tento strom udržovat, počínaje vydáním verze 2.6.11.1. Od té doby Greg udržuje stabilní stromy. Nedávno se ale podělil o svá trápení s procesy.

Zejména pak oznámení o revidování vydání 3.10.1 zahrnovalo hlasitou stížnost na to, jak správci subsystémů spravují patche pro stabilní strom. Konkrétně by rád viděl, kdyby se změnily dvě následující věci:

• Některé patche označené jako pro stabilní vydání tam jednoznačně nepatří. Kosmetické změny v ladících zprávách budiž příkladem.
• Důležitější věc: mnoho patchů označených pro stabilní strom jde během začleňovacího okna do stabilní řady. V mnoha případech to znamená, že si je správce tohoto systému po nějakou dobu syslil – možná měsíce – místo toho, aby je tlačil Linusovi do pozdějšího vydání -rc. Pokud jsou patche dostatečně důležité na to, aby šly do stabilního stromu, ptá se Greg, proč nejdou rovnou k Linusovi?

Odpověď na druhou stížnost je docela jasná: přesvědčit Grega, aby přijal změny do stabilního stromu, je snazší, než přesvědčit Linuse, aby je přijal mimo začleňovací okno. Teoreticky jsou pravidla pro začlenění v obou případech stejná: patche musí řešit nějaký „kritický“ problém. V praxi to vypadá, že Greg a Linus alespoň zdánlivě tato pravidla chápou odlišně. Proto vývojáři, než aby riskovali rozčilení Linuse, jednoduše počkají na následující začleňovací okno. Jak to ostatně vysvětlil James Bottomley:

Myslíš to, že zdržujeme opravy až do začleňovacího okna (ty označené pro stable), protože je nemůžeme dostat do -rc5 nebo pozdějších? Jsem vinen... to proto, že dostat něco do jádra je čím dál těžší. Dostat tam něco drobného po -rc5 je velký boj... je snazší to tiše označit pro stable.

Gregův plán na zlepšení spočívá ve sledování linux-next počínaje -rc4. Pokud se patche označené pro stable začnou objevovat ve stable, pak se bude ptát správců, proč se ještě nedostaly k Linusovi. Některé z těchto patchů nemusejí být přijaty do stabilního stromu, pokud se objeví v hlavní řadě během začleňovacího okna.

Téma nevhodných patchů, ačkoliv tvořilo menší část Gregových stížností, se stalo důležitější částí následující debaty. Vypadá to, že se najdou důvody, proč patche směřovat do stabilního stromu, i když pro něj nejsou úplně vhodné. Jedním extrémním případem, který strojí za přečtení, je ten od Bena Herrenschmidta – popisuje, jak potřeba dostat kód do enterprise jader pohání vývojový proces. V ostatních případech jsou ale důvody spíše přímočařejší.

Celé roky měli lidé obavy, že jsou důležité opravy přehlíženy a nedostávají se do stabilních aktualizací; to vedlo k tlaku na vývojáře, aby příslušné patche připravovali pro stabilní strom. Toto úsilí bylo docela úspěšné, a to dokonce tak, že vývojáři nyní často přidávají tag „stable“ k patchi opravujícímu chybu už jen ze zvyku. Správci subsystémů by měli tyto tagy revidovat při revizi patche, ale k tomu nemusí vždy dojít – nebo tito správci mohou souhlasit s tím, že patch má jít do stabilního stromu, i když nesplňuje pravidla. A občas správci subsystémů nemohou tag odstranit, i když chtějí. Toto všechno vedlo Jamese k návrhu tagu stable se zbavit:

Skutečným původcem problému je to, že tag cc: stable nelze odstranit, jakmile je ve stromu, takže správci mají možnost kontrolovat jen věci, co do stromu dávají. Věci, které přetahují od jiných, jsou už otagované a tento tag nelze změnit. To ve výsledku přenáší problém na nejnižší (a možná i nejméně zkušené) listy ve Stromu správců.

James (stejně jako jiní) navrhuje, aby zařazení patche do stabilního stromu vyžadovalo explicitní úkon ze strany správce subsystému. Ale Gregovi se tento nápad nelíbí, jelikož správci jsou už tak moc zaneprázdnění. Smyslem procesu pro stabilní stromy je věci pro všechny ostatní co nejvíce usnadnit; přidávání zátěže by mohlo úspěch ohrozit. To platí i kvůli tomu, že někteří vývojáři by mohli narazit u svých zaměstnavatelů:

A nejvíce mě rozčiluje to, že některé firmy mají pocit, že s nimi stabilní jádra soupeří. Proto se lidé pracující pro tyto firmy nemusejí setkat s pochopením, když by pro stabilní vydání jader měli dělat práci navíc (to nejsou jen babské povídačky, toto jsem slyšel přímo z úst manažerů).

Dalším zastáncem zapojení správců v procesu je Jiří Kosina, který během své práce na jádrech v SUSE narazil na několik problémů se stabilními jádry. Ačkoliv si stabilního stromu vysoce cení, některé patche v něm způsobují regrese, některé jsou zkrátka na nic a u některých není vůbec jasné, proč jsou ve stabilním stromě. Kdyby správci byli nuceni explicitně vybírat patche a odůvodňovat jejich zařazení do stabilního stromu, pak by podle něj všechny tři typy problémů byly vyřešeny.

První typ – patche, které samy zanášejí chyby – asi nikdy nebude úplně odstraněn; tak to zkrátka při vývoji softwaru chodí. Každý, kdo se do debaty zapojil, odsouhlasil, že jakmile je chybná oprava odhalena, Greg má rychle udělat stabilní vydání bez tohoto patche, takže regrese mizí rychle. Mezi zbytečné patche patří ty, které jsou backportovány do jader předcházejících tomu, kde se původní chyba objevila; tomu by se dalo předejít zahrnutím více informací do seznamu změn. Posledním typem, na který Jiří upozornil – záhadné patche – jsou, jak se ukázalo, bezpečnostní opravy. Jiří (a ostatní) by byli rádi, kdyby bezpečnostní opravy byly v seznamu změn vyznačené, ale to se asi nestane; místo toho se pracuje na upozorňování distributorů na bezpečnostní opravy skrze neveřejné kanály.

Jinými slovy: i když se pravděpodobně budou dělat nějaké změny, nebudou až tak zásadní. Greg asi bude vybíravější ohledně toho, co do stabilního stromu přijme. Asi ale nikdy nebude tak tvrdý jako Linus. Konec konců, uživatelé stabilního stromu – distributoři i koncoví uživatelé – chtějí, aby se do něj opravy dostávaly. Stabilní řady jádra jsou jedním z největších úspěchů v procesu vývoje jádra; jakékoliv změny v tom, jak se vytvářejí, budou pravděpodobně malé. Z pohledu většiny z nás budou opravy proudit dál jako obvykle.

       

Komentáře

[Jardík]

Že by? Že by bylo konečně na linuxu možné vytvořit dočasný soubor? Do teď to možné nebylo, resp. bylo to nebezpečné kvůli race condition mezi open() a unlink(). Chápu to tedy správně, že O_TMPFILE vytvoří soubor beze jména a po close() bude tedy smazán, stejně jako v případě open+unlink+close?

[R]

Ano, chapes to spravne.

[sfsdfsdfsdf]

aka je race condition medzi open() a unlink() ? napada ma jedine crash/segfault medzi open a unlink.

[Vladimír Čunát]

Nebo by ten soubor někdo mohl otevřít.

[Jardík]

Race condition mezi open() a unlink je, že po open() může soubor někdo/něco smazat a vytvořit jiný s tím názvem před unlink() a tak smažete úplně něco jiného. Nebo by tam někdo mohl mezi tím připojit jiný filesystém a opět smažete něco jiného. Tomu druhému případu lze předejít otevřením adresáře a užitím openat() a unlinkat(), ale prvnímu případu nezabráníte. Ano, můžete říct, že je to velmi nepravděpodobné, že mezi open() a unlink() nikdo nic nestihne, ale také může na open() třeba hodit breakpoint a mít dost času, či tak něco. Race-condition tam je, bohužel.

[HonzaRez]

„Linux pro pracovní skuoiny“